AWS classic LB更改IP /丢弃连接会导致RabbitMQ上的消息丢失

Question

我运行一个拥有3个节点的兔HA群集，并在它们前面使用经典的AWS负载均衡器（LB）。有两个应用程序，一个发布，另一个通过LB消费。 当发布者应用程序开始发送300万条消息时，在短时间内将其连接置于流控制状态。发布完成后，在发布者应用程序日志中，我可以看到所有300万条消息都已发送。另一方面，在消费者应用程序日志中，我只能看到500K - 1M消息（在运行之间有所不同），这意味着大量消息丢失。

所以正在发生的事情是，在运行过程中，经典LB决定更改其IP地址或删除连接，从而丢失大量消息（有关更多详细信息，请参阅我的更新）。

如果我跳过LB并直接命中节点，在app端进行负载平衡，则不会出现此问题。当然，在这种情况下，我失去了ELB的所有好处。

我的问题是：

• 为什么LB更改IP地址和丢弃连接，是否与发布者或流控制状态的高消息率有关？
• 如何配置LB，以便此问题不会发生？

更新

这是我对正在发生的事情的理解： 我使用AMQP 0-9-1并在没有＆＃39; 发布确认＆＃39;的情况下发布，因此一旦消息被发送，就会认为该消息已发送。此外，rabbitmq节点上的连接是在LB和节点之间，而不是Publisher应用程序和节点。

1. 在通信进入流量控制之前，消息立即从LB传递到节点

2. 然后LB和节点之间的连接进入Flow Control，Publisher App连接没有被阻止，因此它继续以相同的速率发布。这会导致消息堆积在LB上。

3. 然后LB因任何原因决定更改IP或断开连接并创建一个新连接，导致所有堆叠的消息丢失。从RabbitMQ日志中可以清楚地看到这一点：

   =警告报告==== 2018年1月6日:: 10：35：50 === 关闭AMQP连接＆lt; 0.30342.375＆gt; （10.1.1.250:29564 - ＆gt; 10.1.1.223:5672）： 客户端意外关闭TCP连接

   = INFO REPORT ==== 201-Jan-2018 :: 10：35：51 === 接受AMQP连接＆lt; 0.29123.375＆gt; （10.1.1.22:1886 - ＆gt; 10.1.1.223:5672）

Answer 1

ELB会在响应流量时缩放地址。新节点出现，并出现在DNS中，然后旧节点最终可能会消失，或者它们可能保持在线状态。

  

它通过利用更大的资源（具有更高性能特征的资源）或更多的个人资源来增加容量。 Elastic Load Balancing服务将在扩展时更新负载均衡器的域名系统（DNS）记录，以便新资源在DNS中注册其各自的IP地址。创建的DNS记录包括60秒的生存时间（TTL）设置，期望客户端至少每60秒重新查找DNS。 （强调加）

     

- 来自“Best Practices in Evaluating Elastic Load Balancing”

您可以在“最佳实践”指南中找到更多有用信息，包括借助AWS支持预热平衡器的概念，以及如何以平衡器可扩展的方式提升测试流量起来。

经典ELB的行为是自动的，用户无法配置。

但是听起来好像你的队列存在配置问题，因为看起来它应该对连接断开更有弹性。

另请注意，AWS Network Load Balancer不会更改其IP地址，也不需要像ELB那样替换资源进行扩展，因为与ELB不同，它似乎不会在隐藏实例上运行 - 它是网络基础设施的一部分，或者至少以这种方式出现。这可能是一个可行的替代方案。

Answer 2

解决方案是使用AWS 网络 LB.网络LB将在Publisher App和rabbitmq节点之间创建连接。因此，如果连接被阻止或丢弃，Publisher将会意识到这一点并采取相应的行动。我已经使用3M消息运行相同的测试，而不是单个消息丢失。

在AWS文档中，有一行解释了行为：

  

保留源IP地址网络负载均衡器保留客户端源IP，允许后端查看IP地址   客户端。然后，应用程序可以进一步使用它   处理

     

来自：https://aws.amazon.com/elasticloadbalancing/details/