Redis Pubsub和消息队列

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

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文件的内容。在这里查看示例。该脚本可能需要适应您的系统。