背景
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.