Redis Pubsub和消息队列

时间:2015-01-02 17:13:18

标签: python redis redis-cli

我的整体问题是:使用Redis for PubSub,当发布商将消息推送到频道的速度超过订阅者能够阅读的消息时,消息会发生什么?

例如,假设我有:

  • 一个简单的发布者以2 msg / sec的速率发布消息。
  • 简单订阅者以1 msg / sec的速率读取消息。

我天真的假设是订阅者只会看到50%的消息发布到Redis上。为了测试这个理论,我写了两个脚本:

pub.py

queue = redis.StrictRedis(host='localhost', port=6379, db=0)
channel = queue.pubsub()

for i in range(10): 
    queue.publish("test", i)
    time.sleep(0.5)

sub.py

r = redis.StrictRedis(host='localhost', port=6379, db=0)
p = r.pubsub()
p.subscribe('test')

while True:
    message = p.get_message()
    if message:
        print "Subscriber: %s" % message['data']
    time.sleep(1)

结果

  • 当我首先运行sub.py时,紧接着pub.py,我发现sub.py实际上显示了所有消息(1-10),一个接一个地延迟了1秒之间。我最初的假设是错误的,Redis正在排队消息。需要更多测试。
  • 当我首先运行pub.py,然后在运行sub.py之前等待5秒时,我发现sub.py仅显示了消息的后半部分(5-10)。我本来会假设这个,但考虑到我以前的结果,我会认为消息排队,这导致我得出以下结论......

结论

  • Redis服务器似乎为每个客户端为每个频道排队消息。
  • 只要客户端正在监听,它读取消息的速度并不重要。只要它已连接,消息将保持为该客户端排队等候该消息。

剩余问题

  • 这些结论是否有效?
  • 如果是这样,客户端/频道消息会排队多长时间?
  • 如果是,是否有redis-cli info命令可以查看排队的邮件数量(对于每个客户端/渠道)?

1 个答案:

答案 0 :(得分:77)

测试有效,但结论部分错误。

Redis不会在pub / sub频道上排队。相反,它倾向于从发布者套接字读取项目,并在所有订阅者套接字中写入项目,理想情况是在事件循环的同一次迭代中。 Redis数据结构中没有任何内容。

现在,正如您所展示的,仍然存在某种缓冲。这是由于使用了TCP / IP套接字和Redis通信缓冲区。

套接字有缓冲区,当然,TCP带有一些流控制机制。它可以避免缓冲区满时丢失数据。如果订户不够快,数据将在其套接字缓冲区中累积。当它已满时,TCP将阻止通信并阻止Redis在套接字中输入更多信息。

Redis还管理输出通信缓冲区(在其中一个套接字之上),以生成使用Redis协议格式化的数据。因此,当套接字的输出缓冲区已满时,事件循环会将套接字标记为不可写,并且数据将保留在Redis输出缓冲区中。

如果TCP连接仍然有效,则数据可以在缓冲区中保留很长时间。现在,socket和Redis输出缓冲区都被绑定了。如果用户真的太慢,并且大量数据累积,Redis最终将关闭与订户的连接(作为安全机制)。

默认情况下,对于pub / sub,Redis的软限制为8 MB,每个连接缓冲区的硬限制为32 MB。如果输出缓冲区达到硬限制,或者它在软限制和硬限制之间保持超过60秒,则与慢速用户的连接将被关闭。

了解待处理邮件的数量并不容易。可以通过查看套接字缓冲区中的挂起信息的大小和Redis输出缓冲区来评估它。

对于Redis输出缓冲区,您可以使用CLIENT LIST command(来自redis-cli)。输出缓冲区的大小在obl和oll字段中返回(以字节为单位)。

对于套接字缓冲区,没有Redis命令。但是,在Linux上,可以构建一个脚本来解释/ proc / net / tcp文件的内容。查看示例here。此脚本可能需要适应您的系统。