我正在运行一个 2 节点 ejabberd 集群（在弹性负载均衡器后面），该集群又与 AWS 上的 3 节点 Riak 集群（再次通过 ELB 连接）。当我通过 Tsung 对平台进行负载测试（创建 50 万个用户注册）时，我注意到 ejabberd 节点的 CPU 利用率彼此相差约 10%。对于 Riak 节点，节点之间的 CPU 和内存利用率相差约 5%。
这些节点具有相同的配置，因此想知道是什么导致了这些不平凡的利用率差异。任何人都可以在这里提出一些光芒/教育我吗？
是由于负载均衡器吗？还是网络影响？我希望一旦形成一个集群（ejabberd 或 Riak KV），节点的行为都是相同的，特别是对于整个数据库跨集群复制的 ejabberd。
并不是说这些差异是一个问题，但在这里了解集群的内部工作原理会很好......
非常感谢。
弹性负载均衡机制
- DNS
- 服务器使用 DNS 轮循机制来确定特定可用性区域中的哪个负载均衡器节点将接收请求
- 所选负载均衡器检查"粘性会话"cookie
- 所选负载均衡器将请求发送到负载最少的实例
更详细地说：
可用区（不太可能出现您的情况）
默认情况下，负载均衡器节点将流量路由到同一可用区内的后端实例。为了确保您的后端实例能够处理每个可用区中的请求负载，每个区域中的实例数量大致相同非常重要。例如，如果您在可用区 us-east-1a 中有 10 个实例，在 us-east-1b 中有 2 个实例，则流量仍将在两个可用区之间平均分配。因此，us-east-1b 中的两个实例必须提供与 us-east-1a 中的十个实例相同的流量。
会话（很可能是您的情况）
默认情况下，负载均衡器将每个请求独立路由到负载最小的服务器实例。相比之下，粘性会话将用户的会话绑定到特定的服务器实例，以便在会话期间来自用户的所有请求都将发送到同一服务器实例。
AWS Elastic Beanstalk 在为应用程序启用粘性会话时使用负载均衡器生成的 HTTP Cookie。负载均衡器使用负载均衡器生成的特殊 Cookie 来跟踪每个请求的应用程序实例。当负载均衡器收到请求时，它会首先检查请求中是否存在此 Cookie。如果是这样，请求将发送到 Cookie 中指定的应用程序实例。如果没有 Cookie，负载均衡器将根据现有负载均衡算法选择应用程序实例。Cookie 插入到响应中，用于将来自同一用户的后续请求绑定到该应用程序实例。策略配置定义 Cookie 到期时间，该过期时间确定每个 Cookie 的有效期。
路由算法（不太可能出现您的情况）
负载均衡器节点使用 minimumconns 路由算法将请求发送到同一可用区内的运行状况良好的实例。最少连接路由算法优先于连接或未完成请求最少的后端实例。
来源：Elastic 负载均衡术语和关键概念
希望对您有所帮助。