Redis Pubsub和消息队列

  • Z时代
  • 2024-01-10
  • 分类：问答

我的总体问题是： 使用Redis for PubSub，当发布者将消息推送到频道中的速度比订阅者能够阅读它们的速度快时，消息会如何处理？

例如，假设我有：

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

  • 一个简单的订户以1 msg / sec的速率读取消息。

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

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第一次运行时，然后等待5秒钟，然后再运行sub.py，我发现sub.py它只显示消息的后半部分（5-10）。我本来会以为这样，但是鉴于我以前的结果，我本以为消息已排队，这导致我得出以下结论：

  • Redis服务器似乎将每个客户端，每个通道的消息排队。

  • 只要客户端正在侦听，读取邮件的速度就无关紧要。只要连接，邮件就将一直在该客户端，该通道的队列中。

  • 这些结论是否正确？

  • 如果是这样，客户端/通道消息将保留多长时间？

  • 如果是这样，是否有redis-cli info命令查看排队的消息数量（对于每个客户端/通道）？

回答：

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

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

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

套接字具有缓冲区，当然，TCP附带一些流控制机制。这样可以避免在缓冲区已满时丢失数据。如果订户不够快，数据将累积在其套接字缓冲区中。充满后，TCP将阻止通信并阻止Redis将更多信息推送到套接字中。

Redis还管理输出通信缓冲区（在套接字的顶部），以生成使用Redis协议格式化的数据。因此，当套接字的输出缓冲区已满时，事件循环会将套接字标记为不可写，并且数据将保留在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文件的内容。在这里查看示例。该脚本可能需要适应您的系统。

以上是 Redis Pubsub和消息队列 的全部内容， 来源链接： utcz.com/qa/423490.html

回到顶部