Redis消息发布订阅的稳定性验证结论

背景

2019年的某个时候, 笔者负责解决公司系统内的基于Redis pubsub + Websocket消息推送的功能稳定性

过程

NODetail
1.初始情况: 笔者发现手写的Jedis客户端容易出现 断连, 每个小时至少发生一次, 时间不定. 没有进行多少次改参数的尝试.(因为已经打算寻找中间件解决方案).
2.第一次改进: 后来考察了Spring Data Redis组件, 非常容易集成, 配置服务器地址 端口 密码, 数据库即可, 简单就是美, 不需要研究那些超时参数 testOnBorrow, 这些中间件的编写者都实践好的. 结果就是稳定运行了一年多. 再也没人说收不到消息推送.
3.第二次改进: 2020年6月份(当前写文时间), 因为业务的关系, 又来处理消息推送相关逻辑, 这时不能是原来的水平, 于是抽空看了一下 Spring Data Redis 现在版本很新, 内置有Lettuce驱动, 于是实验了一下 Lettuce, 写一个小SpringBoot应用 放一个晚上. 经过初步的观察, Lettuce的性能更强, 更加关注连接的稳定性, ConnectionWatchdog会自动重连(Jedis Connection Factory的重连是Spring Data Redis提供的, 也会重连, 也有时间间隔可以修改), 而且非常迅速, 因此, 遂打算将Jedis驱动换成 Lettuce驱动.

结论

这个问题不大不小, 对于消息推送的稳定性因素 有很多:

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

没必要深究

解决方案

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

相关推荐