刚刚研究了 Elastic Load Balancer。据我所知，它们只是进行轮询，将连接均匀地分布到它们后面的服务器。那么，如果 ELB 后面有不同大小的实例，会发生什么情况？它会向较大的实例发送更多连接，还是继续均匀分布连接，这意味着您真的不应该使用不同大小的实例。
答案1
据我了解，他们只是进行循环，均匀地分配到他们后面的服务器的连接。
有点，但我认为不完全是——不幸的是，亚马逊 ELB路由文档并非不存在，因此需要汇总一些信息才能得出结论。以下是来自Elastic Load Balancing 开发人员指南我知道，请参阅粘性会话在Elastic Load Balancer 概述：
默认情况下，负载均衡器将每个请求独立路由到负载最小的应用程序实例但是，您可以使用粘性会话功能（也称为会话亲和性），该功能使负载平衡器能够将用户的会话绑定到特定的应用程序实例。这可确保会话期间来自用户的所有请求都将发送到同一个应用程序实例。[重点是我的]
现在最小负载到底是什么意思？同样，我唯一知道的解释是 2009 年 AWS 团队对ELB 策略：
ELB 松散地跟踪每个实例上有多少个未完成的请求（或 TCP 情况下的连接）。 它不会监控每个实例的资源使用情况（例如 CPU 或内存）。ELB 目前将在其认为未完成请求最少的实例之间进行循环调度。[重点是我的]
这对于他们的系统架构和所涉及的用例来说很有意义，但显然不能提供您可能需要的高级 HA 场景的透明度和/或路由控制。
请注意，根据不同的解释，这可能会或可能不会与 AWS 团队最近对以下问题的回应相矛盾：Elastic Load Balancing - 负载分配策略：
循环确实发挥了作用，但客户端会话并不总是遵守 TTL 或 DNS 缓存，因此您可能会得到不准确的结果和不均匀的请求分布。ELB 不会将实例在其流量路由决策中迄今为止收到的流量/请求考虑在内。 [重点是我的]
健康检查
当然，以上内容是经过适当记录、透明和可控的修改的健康检查，这给你一些杠杆来（可能是暂时的）首先将实例从路由中删除，正如上述 AWS 团队对ELB 策略以及：
负载均衡器会监控您在负载均衡器上注册的实例的运行状况。当负载均衡器检测到某个实例出现问题时，它会停止向该实例分配流量。当该实例恢复正常时，负载均衡器会重新开始向该实例分配流量。此过程允许您的应用程序自动对失败的实例做出反应，除了配置运行状况检查之外，您无需参与其他操作。
结论
虽然这确实不常见，但我不明白为什么 ELB 不能与不同的池一起工作Amazon EC2 实例类型我自己还没有尝试过，但我推荐这两种方法，使用 CloudWatch 监控您的负载均衡器以及监控您的各个 EC2 实例并关联结果以便最终获得对这种设置的相应见解和信心。
答案2
根据迄今为止的陈述，分发算法非常简单。
ELB的前端一般是多个ELB实例，并且采用循环分配的方式。
后端（您的实例）算法声称是：
ELB 大致跟踪每个实例上有多少请求（或 TCP 情况下的连接数）。它不监控每个实例上的资源使用情况（例如 CPU 或内存）。ELB 目前将在它认为具有最少未完成请求的实例之间进行轮询。
这意味着如果一个较大的实例有较少的未完成请求，那么更多的流量将被路由到它们。没有办法保证这一点。