python redis 消息队列 回调_Redis Pubsub和消息队列

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

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

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

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

Redis还管理输出通信缓冲区(位于套接字的顶部)，以生成使用Redis协议格式化的数据。因此，当套接字的输出缓冲区已满时，事件循环将套接字标记为不可写，数据将保留在Redis输出缓冲区中。

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

默认情况下，对于pub/sub，Redis对每个连接缓冲区的软限制为8mb，硬限制为32mb。如果输出缓冲区达到硬限制，或者在软限制和硬限制之间保持60秒以上，则将关闭与慢速订户的连接。

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

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

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