使用 Redis 作为 AWS 负载均衡器

Question

我们正在使用 Redis 从 AWS ELB 后面的 Web 应用程序（基于发布/订阅）收集事件。 我们正在寻找一种解决方案，使我们能够针对不同的服务器进行扩展和高可用性。我们不希望将这两个服务器放在 Redis 集群中，我们的计划是使用 cloudwatch 监控它们，并在必要时在它们之间切换。

我们尝试了一个简单的测试，即在 ELB 后面定位两个 Redis 服务器，远程登录 ELB DNS 并使用“redis-cli monitor”查看会发生什么，但我们什么也没看到。 （在没有 ELB 的情况下尝试同样的方法似乎很好）

有什么建议吗？

谢谢

Answer 1

我在寻找类似问题时遇到了这个问题，但不同意接受的答案。尽管这已经很老了，但希望它对将来的人有所帮助。

对于您的问题，将 DNS 故障转移与 Redis 复制自动故障转移配置一起使用更合适。 DNS 故障转移提供可用性组（如果您需要该级别的规模），而复制组提供缓存运行时间。

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

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

主动-被动故障转移：根据需要使用此故障转移配置 大部分时间可用的主要资源组 并且您希望备用资源组以防万一 所有主要资源都变得不可用。回复的时候 查询，Amazon Route 53 仅包含健康的主要资源。 如果所有主要资源均不正常，Amazon Route 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

Answer 2

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

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

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

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

Answer 3

假设您在 VPC 中运行：

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

如果 ELB 认为其背后的服务器不健康，则 ELB 不会向它们发送任何流量。