Redis 发布订阅和消息队列

Question

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

例如，假设我有：

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

我的天真假设是订阅者只会看到发布到 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 命令查看排队的消息数量（针对每个客户端/通道）？

Answer 1

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

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

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

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

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

如果 TCP 连接仍然有效，数据可以在缓冲区中保留很长时间。现在，套接字和 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。该脚本可能需要适应您的系统。