python - Redis 发布订阅和消息队列

Question

我的总体问题是:将 Redis 用于 PubSub，当发布者将消息推送到 channel 的速度快于订阅者能够读取它们的速度时，消息会发生什么？

例如，假设我有:

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

我的天真假设是订阅者只会看到发布到 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 服务器似乎为每个客户端、每个 channel 的消息排队。
• 只要客户端在监听，它读取消息的速度就没有关系。只要它处于连接状态，消息就会一直为该客户端、该 channel 排队。

剩下的问题

• 这些结论有效吗？
• 如果是这样，客户端/ channel 消息将在队列中保留多长时间？
• 如果有，是否有 redis-cli info 命令查看排队的消息数量(针对每个客户端/ channel )？

Answer 1

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

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

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

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

Redis 还管理输出通信缓冲区(在套接字之上)以生成使用 Redis 协议(protocol)格式化的数据。所以当socket的输出缓冲区满时，事件循环会将socket标记为不可写，数据会留在Redis的输出缓冲区中。

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

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

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

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

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