我的总体问题是： 使用Redis for 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)

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