73

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

例如，假设我有：

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

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

发布.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)

子.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命令查看排队的消息数量（对于每个客户端/通道）？
4

1 回答 1

138

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

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

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

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

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

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

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

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

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

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

于 2015-01-02T18:23:24.407 回答