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提供的, 也会重连, 也有时间间隔可以修改), 而且非常迅速, 因此, 遂打算将Jedis驱动换成 Lettuce驱动. |
结论
这个问题不大不小, 对于消息推送的稳定性因素 有很多:
- 服务端自动断开, 可能设置了最大会话长度等等, 例如 1小时.
- 客户端网络环境问题
- 根本不是参数问题
没必要深究
解决方案
- Spring Data Redis 足够满足需求
- 或许可以选择Lettuce作为 Spring Data Redis的底层驱动
- 对这个稳定性要求更高的 可以用 Kafka/Rabbit MQ等 其他专门做发布订阅的消息队列中间件.
- 甚至可以不用websocket, 直接接口 poll.
相关推荐
smartbaby 2020-11-11
ljz0 2020-09-15
王道革 2020-11-25
wangdonghello 2020-11-03
Langeldep 2020-11-16
chenhualong0 2020-11-16
聚合室 2020-11-16
koushr 2020-11-12
MRFENGG 2020-11-11
guoyanga 2020-11-10
fackyou00 2020-11-10
Orangesss 2020-11-03
dongCSDN 2020-10-31
rainandtear 2020-10-30
Quietboy 2020-10-30
liuyulong 2020-10-29
fansili 2020-10-29
温攀峰 2020-10-23