我正在运行一个双节点ejabberd集群（位于弹性负载均衡器后面），该节点依次连接3节点Riak集群（再次通过ELB）在AWS上。当我通过Tsung（创建50万用户注册）对平台进行负载测试时，我注意到ejabberd节点的CPU利用率相差10％左右。对于Riak节点，节点间的CPU和内存利用率相差约5％。AWS上的ejabberd和Riak集群的CPU和内存利用率差异
节点具有相同的配置，所以不知道可能导致这些利用率的重要差异。任何人都可以在这里请一些灯/教育我？
是否由于负载平衡器？还是网络影响？我期望一旦集群形成（ejabberd或Riak KV），节点的行为都是相同的，特别是对整个数据库跨集群复制的ejabberd。
这并不是说这些差异是一个问题，但将是很好的了解这里的集群的内部运作...
非常感谢。
弹性负载平衡机制
个更具体：
可用性区域（不太可能你的情况）
默认情况下，负载均衡器节点流量路由到同一个可用性区域内的后端实例。为了确保您的后端实例能够处理每个可用区中的请求负载，每个区域中具有大致相同数量的实例很重要。例如，如果您在可用区us-east-1a中有十个实例，而在us-east-1b中有两个实例，则流量仍将在两个可用区之间平均分配。结果，我们东部的两个实例1b将不得不服务于与我们东部1a的十个实例相同的流量。
会议（最有可能你的情况）
默认情况下，负载均衡路线，每条路线的要求独立的服务器实例负载最小。相比之下，粘性会话会将用户的会话绑定到特定的服务器实例，以便会话期间来自用户的所有请求都将发送到同一个服务器实例。
AWS Elastic Beanstalk在为应用程序启用粘性会话时使用负载均衡器生成的HTTP cookie。负载均衡器使用特殊的负载均衡器生成的cookie来跟踪每个请求的应用程序实例。当负载均衡器收到一个请求时，它首先检查这个cookie是否存在于请求中。如果是这样，请求将发送到cookie中指定的应用程序实例。如果没有cookie，负载均衡器会根据现有的负载均衡算法选择一个应用程序实例。将Cookie插入到响应中，以便将来自同一用户的后续请求绑定到该应用程序实例。策略配置定义了一个cookie到期时间，它为每个cookie确定有效期。
路由算法（不太可能你的情况）
负载平衡器节点发送使用leastconns路由算法的请求到相同的可用性区域内健康实例。路由算法偏向于具有最少连接或未完成请求的后端实例。
来源：Elastic Load Balancing Terminology And Key Concepts
希望它帮助。
非常感谢@ error2007s ...非常赞赏详细的说明。有趣的是，注意到粘性会话的概念 - 并没有意识到这一点。也就是说，我仍然不希望任何负载均衡器生成的cookie被重用，因为每个用户在负载测试期间只发送一个用户创建请求，并且没有任何后续事件。因此理想情况下，负载平衡器应该对2个ejabberd实例（已经在不同的AZ中）具有相同的行为（至少在理论上）。 – vikram17000
如果你明白了差异，请标记我的答案正确。 – error2007s
不同意10％意味着你可以给出两个节点ejabberd集群的实际数字吗？ – error2007s
嗨@ error2007s - 百分比大约是50和62％... – vikram17000