使用Redis Behing AWS负载均衡器 [英] Using Redis behing AWS load balancer

问题描述

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

We're using Redis to collect events from our web application (pub/sub based) behind AWS ELB. We're looking for a solution that will allow us to scale-up and high-availability for the different servers. We do not wish to have these two servers in a Redis cluster, our plan is to monitor them using cloudwatch and switch between them if necessary.

我们尝试了一个简单的测试，即在ELB后面放置两个Redis服务器，对ELB DNS进行远程登录，然后使用"redis-cli monitor"查看会发生什么，但是我们什么也没看到. (在没有ELB的情况下尝试相同的操作似乎很好)

We tried a simple test of locating two Redis server behind the ELB, telnetting the ELB DNS and see what happens using 'redis-cli monitor', but we don't see nothing. (when trying the same without the ELB it seems fine)

有什么建议吗?

谢谢

推荐答案

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

Placing a pair of independent redis nodes behind a LB will likely not be what you want. What will happen is ELB will try to balance connections to each instance, splitting half to one and half to another. This means that commands issued by one connection may not be seen by another. It also means no data is shared. So client a could publish a message, and client b being subscribed to the other server won't see the message.

对于ELB后面的PUBSUB，您有另一个问题. ELB将关闭空闲连接.因此，如果您订阅的频道不忙，则ELB将关闭您的连接.记得我最多可以将其设置为60秒，这意味着如果您不每隔一分钟发布一条消息，则客户端将断开连接.

For PUBSUB behind ELB you have a secondary problem. ELB will close an idle connection. So if you subscribe to a channel that isn't busy your ELB will close your connection. As I recall the max you can make this is 60s, meaning if you don't publish a message every single minute your clients will be disconnected.

关于多少问题取决于您的客户端库，并且坦率地说，根据我的经验，大多数问题处理得不好，因为他们不知道需要在重新建立连接时重新订阅，这意味着您将不得不自己编写代码.

As to how much of a problem that is depends on your client library, and frankly in my experience most don't handle it well in that they are unaware of the need to re-subscribe upon re-establishing the connection, meaning you would have to code that yourself.

这表示，如果您的c没有适当的哨兵支持，则哨兵+ redis解决方案将是非常理想的.在这种情况下.您的客户要求哨兵与主机对话，如果连接失败，它将重复此过程.这将处理您描述的设置，而不会出现在ELB后面的问题.

That said a sentinel + redis solution would be quite ideal if your c,isn't has proper sentinel support. In this scenario. Your client asks the sentinels for the master to talk to, and on a connection failure it repeats this process. This would handle the setup you describe, without the problems of being behind an ELB.

这篇关于使用Redis Behing AWS负载均衡器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！