Redis Pubsub和消息队列

Question

我的总体问题是：使用Redis for PubSub，当发布者将消息推送到一个比订阅者能够读取消息更快的频道时，消息会发生什么情况？

例如，假设我有：

• 一个简单的发布者以每秒2毫秒的速度发布消息。
• 一个简单的订阅者以每秒1msg的速度读取消息。

我天真的假设是订户只能看到50%的消息发布到Redis上。为了验证这个理论，我写了两个剧本：

公共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)

子年度

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命令来查看（每个客户机/通道）排队的消息数？

Answer 1

测试是有效的，但结论部分是错误的。

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

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

套接字有缓冲区，当然，TCP还带有一些流控制机制。它避免了在缓冲区已满时丢失数据。如果订阅服务器不够快，数据将积累在其套接字缓冲区中。当它已满时，TCP将阻止通信并阻止Redis在套接字中推送更多信息。

Redis还管理输出通信缓冲区（位于套接字的顶部），以生成使用Redis协议格式化的数据。因此，当套接字的输出缓冲区已满时，事件循环将套接字标记为不可写，数据将保留在Redis输出缓冲区中。

如果TCP连接仍然有效，数据可以在缓冲区中保留很长时间。现在，套接字和Redis输出缓冲区都已绑定。如果订阅服务器太慢，大量数据积累，Redis最终会关闭与订阅服务器的连接（作为一种安全机制）。

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

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

对于Redis输出缓冲区，可以使用CLIENT LIST command（来自Redis cli）。输出缓冲区的大小在obl和oll字段中返回（字节）。

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