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. 服务端自动断开, 可能设置了最大会话长度等等, 例如 1小时.
2. 客户端网络环境问题
3. 根本不是参数问题

没必要深究

解决方案

1. Spring Data Redis 足够满足需求
2. 或许可以选择Lettuce作为 Spring Data Redis的底层驱动
3. 对这个稳定性要求更高的 可以用 Kafka/Rabbit MQ等 其他专门做发布订阅的消息队列中间件.
4. 甚至可以不用websocket, 直接接口 poll.