使用Redis behing AWS负载平衡器
我们使用Redis从AWS ELB后面的我们的Web应用程序（基于pub/sub的）收集事件。 我们正在寻找一种解决方案，使我们能够为不同的服务器提供更高的可用性和更高的可用性。我们不希望这两个服务器位于Redis群集中，我们的计划是使用cloudwatch监控它们，并在必要时在它们之间切换。使用Redis behing AWS负载平衡器
我们试着在ELB后面定位两个Redis服务器，远程登录ELB DNS并查看使用'redis-cli monitor'会发生什么，但我们什么也没看到。 （当试图没有ELB的情况下，似乎很好）
有什么建议吗？
感谢
将一对独立的redis节点放在LB后面可能不是您想要的。 ELB将会尝试平衡每个实例的连接，将一半一半分成另一半。这意味着一个连接发出的命令可能不会被另一个连接看到。这也意味着没有数据被共享。因此，客户端a可以发布消息，并且客户端b正在订阅其他服务器将看不到消息。
对于ELB背后的PUBSUB，你有第二个问题。 ELB将关闭一个空闲连接。所以如果你订阅了一个不忙的频道，你的ELB将关闭你的连接。正如我记得的最大你可以使这是60秒，这意味着如果你不发布消息每隔一分钟你的客户将被断开。
至于多少问题取决于您的客户端库，并且坦率地说，根据我的经验，大多数人不能很好地处理它，因为他们不知道重新建立连接时需要重新订阅，这意味着你必须自己编码。
这就是说如果你的c没有正确的定点支持，那么sentinel + redis解决方案将会非常理想。在这种情况下。您的客户请求主人与哨兵通话，并在连接失败时重复此过程。这将处理你描述的设置，而不会出现ELB背后的问题。
假设你在VPC运行：
- 你已经注册与ELB的EC2实例？
- 您是否向ELB添加了正确的安全组设置（允许入站端口23）？
- 您是否添加了一个将ELB上的端口23映射到实例上的端口23的ELB侦听器？
- 您是否设置了合理的ELB健康检查（例如端口23上的TCP），以便ELB认为EC2实例是健康的？
如果ELB认为背后的服务器不健康，那么ELB不会发送任何流量。
我在查找类似问题时遇到了这个问题，但不同意接受的答案。尽管这已经很老了，但希望它能帮助未来的某个人。
对于您的问题，使用DNS故障转移和Redis复制自动故障切换配置更合适。 DNS故障转移提供了可用性组（如果您需要这种级别的缩放）并且复制组提供缓存运行时间。
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html
主动 - 被动故障转移应提供你与高可用性想要的解决方案：
主动 - 被动故障转移：当你想 资源的主要组使用此故障转移配置可用的大部分时间 和你想要的资源的次要组待命，以防 所有的主要资源的不可用。在响应 查询时，Amazon Route 53仅包含健康的主要资源。 如果所有的主要资源的是不健康的，亚马逊路线53开始 到包括响应于DNS查询 只健康二次资源。
设置完DNS后，您将指向Elasticache Redis故障转移组的URL并在故障转移操作期间添加多个组以获得更高的可用性。
但是，您可能需要设置您的应用程序编写，并从不同的端点读取最大化架构的可扩展性。
来源：
http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Replication.html http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/AutoFailover.html
1，2，3，4 - >是肯定的。实际完成所有步骤之前，我们无法初始化所有的telnet会话（得到了一个错误），ELB看到两个实例为在职（健康）。顺便说一句 - 不知道为什么你说的23端口，当Redis的上6379.监听当实例的每一个打开一个telnet会话127.0.0.1:6379似乎罚款... – user2928842
奇。对于使用IGW的VPC中ELB背后的单个支持telnet的Amazon Linux实例，这适用于我。听众映射和健康检查是关键。 – jarmod