Redis发布/订阅和消息队列

Question

Redis发布/订阅和消息队列

pythonredisredis-cli

81

总的问题是：在使用 Redis 进行发布订阅时，当发布者将消息推送到频道的速度快于订阅者读取消息的速度时，会发生什么？

例如，假设我有：

一个简单的发布者，每秒发布2个消息。
一个简单的订阅者，每秒读取消息1次。

我天真地认为订阅者只能看到Redis上发布的50%的消息。为了测试这个理论，我编写了两个脚本：

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，然后等待5秒钟再运行sub.py时，我发现sub.py只显示了消息的后半部分（5-10）。原本我会这样假设，但考虑到之前的结果，我认为消息已经排队，这导致我得出了以下结论...

结论

Redis服务器似乎为每个客户端、每个通道排队消息。
只要客户端在监听，无论读取消息有多快都不重要。只要它保持连接，消息就会为该客户端、该通道保留在队列中。

剩余问题

这些结论是否有效？
如果有效，客户端/通道消息将保留多长时间？
如果有效，是否有一个redis-cli info命令可以查看有多少消息排队（对于每个客户端/通道）？

- Marco Benvoglio

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Didier Spezia · Accepted Answer

测试是有效的，但结论部分是错误的。 Redis不会在发布/订阅通道上排队任何内容。相反，它倾向于从发布者套接字中读取项目，并将项目写入所有订阅者套接字中，理想情况下在事件循环的同一次迭代中完成。在Redis数据结构中没有保留任何内容。现在，正如您所证明的那样，仍然存在某种缓冲。这是由于使用TCP/IP套接字和Redis通信缓冲区引起的。套接字具有缓冲区，当然，TCP带有一些流量控制机制。当缓冲区满时，它避免了数据丢失。如果订阅者不够快，数据将在其套接字缓冲区中积累。当它满时，TCP将阻止通信并防止Redis将更多信息推送到套接字中。 Redis还管理输出通信缓冲区（在套接字的缓冲区之上）以生成使用Redis协议格式化的数据。因此，当套接字的输出缓冲区已满时，事件循环将标记套接字为不可写，并且数据将保留在Redis输出缓冲区中。只要TCP连接仍然有效，数据就可以在缓冲区中保留很长时间。现在，套接字和Redis输出缓冲区都受到限制。如果订阅者真的太慢，并且积累了大量数据，Redis最终将关闭与订阅者的连接（作为安全机制）。

默认情况下，对于发布/订阅，Redis在每个连接缓冲区中有一个8 MB的软限制和32 MB的硬限制。如果输出缓冲区达到硬限制，或者保持在软限制和硬限制之间超过60秒，与慢速订阅者的连接将被关闭。

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

对于Redis输出缓冲区，您可以使用CLIENT LIST命令（从redis-cli）。输出缓冲区的大小以字节形式返回在obl和oll字段中。

对于套接字缓冲区，没有Redis命令。但是，在Linux上，可以构建一个脚本来解释/proc/net/tcp文件的内容。在这里看一个例子。该脚本可能需要根据您的系统进行适应。