问使用Redis贝希AWS负载均衡器

EN

在LB后放置一对独立的redis节点可能不是您想要的。将发生的是ELB将尝试平衡与每个实例的连接，将一半分配给一个，另一个分给另一个。这意味着由一个连接发出的命令可能不会被另一个连接看到。这也意味着没有数据共享。因此，客户机a可以发布消息，而订阅到另一个服务器的客户端b将看不到消息。

对于ELB背后的PUBSUB，您有一个次要的问题。ELB将关闭空闲连接。因此，如果您订阅的频道不忙，您的ELB将关闭您的连接。我记得你能做到的最大限度是60岁，这意味着如果你不每分钟发布一条信息，你的客户就会被断开连接。

至于有多少问题取决于您的客户端库，坦率地说，在我的经验中，大多数人没有很好地处理它，因为他们不知道在重新建立连接时需要重新订阅，这意味着您必须自己编写代码。

也就是说，如果c没有适当的哨兵支持，那么哨兵+ redis解决方案将是非常理想的。在这种情况下。您的客户端要求主程序与主程序交谈，如果连接失败，则重复此过程。这将处理您描述的设置，而不会出现在ELB后面的问题。

我在寻找类似的问题时遇到了这个问题，但不同意接受的答案。虽然这是相当古老的，但希望它能在未来帮助到某人。

这里使用DNS故障转移和Redis复制自动故障转移配置更为合适。DNS故障转移提供了可用性组(如果需要这种级别的话)，复制组提供缓存启动时间。

http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html

主动-被动故障转移应该提供高可用性所需的解决方案：

主动-被动故障转移:当您希望一组主资源在大部分时间可用时，并且希望备用一组资源处于备用状态时，请使用此故障转移配置，以防所有主资源不可用。在回答查询时，Amazon 53只包含健康的主要资源。如果所有的主要资源都是不健康的，则为了响应DNS查询，Amazon 53开始只包含健康的辅助资源。

在您设置DNS之后，您将指向Elasticache故障转移组的URL，并在故障转移操作期间为更高的可用性添加多个组。

但是，您可能需要设置您的应用程序，以便从不同的端点进行写入和读取，以最大限度地提高体系结构的可伸缩性。

资料来源：

http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Replication.html http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/AutoFailover.html

假设您在VPC中运行：

1. 您是否将EC2实例注册到ELB？
2. 是否将正确的安全组设置添加到ELB (允许入站端口23)？
3. 您是否添加了一个ELB侦听器，它将ELB上的端口23映射到实例上的端口23？
4. 您是否设置了合理的ELB健康检查(例如，端口23上的TCP )以使ELB认为EC2实例是健康的？

如果ELB认为背后的服务器不健康，那么ELB就不会给他们发送任何流量。