Redis消息发布订阅的稳定性验证结论
背景
2019年的某个时候, 笔者负责解决公司系统内的基于Redis pubsub + Websocket消息推送的功能稳定性
过程
| NO | Detail |
|---|---|
| 1. | 初始情况: 笔者发现手写的Jedis客户端容易出现 断连, 每个小时至少发生一次, 时间不定. 没有进行多少次改参数的尝试.(因为已经打算寻找中间件解决方案). |
| 2. | 第一次改进: 后来考察了Spring Data Redis组件, 非常容易集成, 配置服务器地址 端口 密码, 数据库即可, 简单就是美, 不需要研究那些超时参数 testOnBorrow, 这些中间件的编写者都实践好的. 结果就是稳定运行了一年多. 再也没人说收不到消息推送. |
| 3. | 第二次改进: 2020年6月份(当前写文时间), 因为业务的关系, 又来处理消息推送相关逻辑, 这时不能是原来的水平, 于是抽空看了一下 Spring Data Redis 现在版本很新, 内置有Lettuce驱动, 于是实验了一下 Lettuce, 写一个小SpringBoot应用 放一个晚上. 经过初步的观察, Lettuce的性能更强, 更加关注连接的稳定性, ConnectionWatchdog会自动重连(Jedis Connection Factory的重连是Spring Data Redis提供的, 重连频率为1小时 也有重连delay可以修改), 而且非常迅速, 因此, 遂打算将Jedis驱动换成 Lettuce驱动. 经过尝试 相同的Redis实例, Lettuce的重连频率时15分钟, 这个由什么决定暂不清楚 |
结论
这个问题不大不小, 对于消息推送的稳定性因素 有很多:
- 服务端自动断开, 可能设置了最大会话长度等等, 例如 1小时.
- 客户端网络环境问题
- 根本不是参数问题
没必要深究
解决方案
- Spring Data Redis 足够满足需求
- 或许可以选择Lettuce作为 Spring Data Redis的底层驱动
- 对这个稳定性要求更高的 可以用 Kafka/Rabbit MQ等 其他专门做发布订阅的消息队列中间件.
- 甚至可以不用websocket, 直接接口 poll.
