redis-rs项目中RESP3推送模型的轮询机制问题分析

redis-rs作为Rust语言实现的Redis客户端库，在处理RESP3协议推送消息时存在一个关键性问题：当前实现仅当连接上有请求发送时才会接收断开连接的推送消息。这个问题直接影响到了Redis的发布订阅、监控和客户端缓存等功能的可靠性。

问题本质

在当前的实现中，无论是同步还是异步连接，都依赖于主动发送请求来触发TCP流量的轮询。这种设计导致了一个明显的缺陷：当客户端处于空闲状态时，即使服务器端发送了断开连接的通知，客户端也无法及时感知。

具体表现为：

• 发布订阅功能可以正常工作
• 监控功能可以接收更新
• 客户端缓存也能获取变更
• 但当连接出现问题时，客户端无法及时收到错误通知

技术影响

这种设计缺陷对不同类型的Redis功能产生了不同程度的影响：

1. 发布订阅模式：虽然可以接收消息，但在服务器断开时无法及时通知客户端
2. 监控功能：同样存在断开连接无法及时感知的问题
3. 客户端缓存：变更通知可以接收，但连接状态变化无法及时获知

解决方案探讨

针对这个问题，社区提出了几种可能的解决方案：

1. 心跳机制：定期发送PING命令来保持连接活跃并检测状态
2. 独立轮询：实现独立的TCP流量轮询机制，不依赖于用户请求
3. 多路复用优化：在复用连接的情况下更容易实现及时的错误检测

与其他客户端的对比

参考其他Redis客户端实现（如rueidis），发现这是一个普遍存在的问题。大多数客户端同样依赖于主动操作来检测连接状态，而不是实现完全独立的轮询机制。

技术决策建议

考虑到问题的严重性，建议在以下两种方案中选择：

1. 作为阻塞性问题处理：在下个版本中修复此问题，确保推送通知的可靠性
2. 标记为实验性功能：暂时将推送管理器标记为beta功能，待完善后再正式发布

从技术实现角度看，实现独立轮询机制虽然会增加一定复杂度，但能提供更可靠的连接状态监控，是更理想的长期解决方案。