我正在准备AWS认证，并且遇到了关于ELB的问题，并为2个AZ中的实例启用了粘性会话。问题是来自其中一个AZ的基于软件的负载测试器的请求最终只在AZ中的实例中，而不是在AZ之间分布。同时，来自客户的定期请求在AZ之间均匀分布。修复负载测试器问题的正确答案是：
我不确定我能理解这种情况。当涉及ELB IP解析时，Route 53的默认行为是什么？无论如何，那些DNS记录有60秒的TTL。在每个请求上重新解析DNS不是多余的吗？此外，DNS解析是DNS服务本身的责任，而不是负载测试软件，不是吗？我可以理解来自相同实例的请求，其上有负载测试软件，将转到相同的LBed EC2，但为什么它必须是同一个AZ中的实例？它只能通过基于地理位置或延迟的路由来实现，但我在规范中找不到这些是否是默认路由。
当ELB位于多个可用区域中时，它始终具有多个公共IP地址 - 每个区域至少有一个。
当您在DNS查找中请求这些记录时，您将获得所有这些记录（假设不是很多）或它们的一部分（如果有大量数据，那么在具有大量流量的活动集群中就是这种情况）但它们是无序的。
如果负载测试软件解析端点的IP地址并且只保留其中一个IP地址 - 这可能是一个结果 - 那么所有流量将转到平衡器的一个节点，该节点位于一个区域中，并将流量发送到该区域中的实例。
但是关于...
跨区域负载平衡
负载均衡器的节点将请求从客户端分发到已注册的目标。启用跨区域负载平衡后，每个负载平衡器节点将在所有已启用的可用区域中的已注册目标之间分配流量。禁用跨区域负载平衡时，每个负载平衡器节点仅在其可用区域中的已注册目标上分配流量。
如果配置了粘性，那些会话将首先落在一个AZ中然后坚持到那个AZ，因为它们坚持到它们着陆的初始实例。如果启用了跨区域，结果就不那么清楚，但是在这种情况下（或者首次建立粘性时），平衡器节点可能更喜欢自己区域中的实例，或者这不是问题的真正要点。粘性需要协调，并且跨AZ流量由于距离（通常<10毫秒）而花费非零时间量，但是平衡器更倾向于选择其本地区域的实例用于没有建立关联的会话。
实际上，配置负载测试软件以重新解析每个请求的端点并不是解决方案的重点 - 关键是要确保（1）负载测试软件使用所有这些并且不会完全锁定一和（2）如果由于平衡器在负载下向外扩展而有更多地址可用，那么负载测试软件会扩展其目标池。
无论如何，那些DNS记录有60秒的TTL。在每个请求上重新解析DNS不是多余的吗？
软件可能看不到TTL，可能不会遵守TTL，并且如上所述，即使有多个可用，也可能会坚持一个答案，因为它只需要一个来进行连接。每个请求都不是绝对必要的，但它确实解决了这个问题。
此外，DNS解析是DNS服务本身的责任，而不是负载测试软件，不是吗？
在这种情况下“解析DNS”只是意味着在特定实例中进行DNS查找，无论是使用操作系统的DNS解析器还是直接查询递归DNS服务器。当软件建立与主机名的连接时，它会“解析”（查找）关联的IP地址。
另一个解决方案“使用第三方负载测试服务发送来自全球分布式客户端的请求”，意外地解决了这个问题，因为分布式客户端 - 即使他们坚持他们看到的第一个地址 - 更有可能看到所有可用的地址。 “全球”分布方面令人分心。
作为平衡策略的一部分，ELB依赖于跨越其面向外部节点的请求的随机到达。设计忽视这一点的负载测试软件没有正确测试ELB。两种解决方案都以不同方式缓解了这个问题。
粘性是问题，请看这里：https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
负载均衡器使用特殊cookie将会话与处理初始请求的实例相关联，但遵循策略配置中指定的应用程序cookie的生命周期。如果应用程序响应包含新的应用程序cookie，则负载均衡器仅插入新的粘性cookie。负载均衡器粘性cookie不会随每个请求更新。如果明确删除或过期应用程序cookie，则在发出新的应用程序cookie之前，会话将停止粘滞。
重新解析DNS的第一个解决方案是创建新会话，这将打破ELB的粘性。第二种解决方案是使用多个客户端，如果全球分布式客户端的数量很大，则粘性不是问题。
第2部分：无法添加评论，是长期：
是的，我的答案是简单和不完整。
我们所知道的是，ELB是2个AZ，并且将有2个具有不同IP的节点。不清楚有多少IP，取决于每个AZ上的请求数和服务器数。路由53为每个新请求旋转IP，第一次在NodeA-IP，NodeB-IP，第二次是NodeB-IP，NodeA-IP。负载测试应用程序将为每个新请求提供第一个IP，在2个AZ之间进行平衡。由于节点只能在其AZ内部路由，如果粘性cookie用于NodeA并且请求到达NodeB，NodeB会将其发送到AZ2中的一个服务器，忽略AZ 1中服务器的cookie。
我需要运行一些测试，使用经典ELB和2 AZ的Route53快速测试，每次IP都会旋转。如果我有AZ 1的粘性cookie并且我到达节点2，我想测试的是不会将我转发到节点1（如果没有可用的服务器，则在文档中描述这个有趣的流程）。希望在短时间内有更新。
刚发现另一条证据表明Route 53返回多个IP并为ELB扩展场景旋转它们：
默认情况下，Elastic Load Balancing将在客户端执行DNS解析时返回多个IP地址，并在每个DNS解析请求上随机排序记录。随着流量配置文件的更改，控制器服务将扩展负载平衡器以处理更多请求，并在所有可用区中进行相同的扩展。
然后：
为了确保客户端利用增加的容量，Elastic Load Balancing在DNS记录上使用60秒的TTL设置。将此更改的DNS记录纳入测试至关重要。如果您不确保重新解析DNS或使用多个测试客户端来模拟增加的负载，则当Elastic Load Balancing实际分配了更多IP地址时，测试可能会继续命中单个IP地址。
我最初没有意识到的是，即使常规流量在AZ之间均匀分布，也不意味着启用了跨区域负载平衡。正如迈克尔指出的那样，定期交通自然会通过不同的地点进入，并最终进入不同的AZ。由于测试中未明确提及，因此可能没有实现跨AZ平衡。
https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/