- 偶然看到的問題技術分享：Spring Boot默認Redis Client Lettuce報出RedisCommandTimeoutException，多臺客戶端集群只有一臺出現報錯，無法立即重連，持續15min后自動恢復報錯消失，再次發現又是15min，過程中Redis沒有宕機。
一、排查過程：
- 從報錯來看，猜測是單純網絡問題，但都是15分鐘后自動恢復，所以猜測并不只是網絡抖動，而且網絡15分鐘以內應該已經恢復，但是客戶端沒有及時重連，所以代碼邏輯上也有問題
- 報錯前客戶端訪問Redis正常，排除長時間閑置導致客戶端斷開，應該并沒有達到本機Keepalive時間（猜測），如果Keepalive超時斷連，客戶端應該也會觸發重連
- 分析Lettuce后，發現Lettuce內部Netty觸發ChannelInactived后就會重連，ChannelInactived是客戶端斷開后的回調，所以猜測客戶端15分鐘后才斷連，觸發了重連
- 然后分析服務端，Redis并沒有重啟，就算進程退出，正常在結束時TCP也會觸發close()，客戶端收到后也會及時退出
- 猜測網絡抖動服務端因為Keepalive關閉連接，FIN并沒有到達客戶端，導致了TCP半打開，這也能解釋客戶端并沒有及時觸發ChannelInactived
- 剩下2個問題，為什么是15分鐘，還有重試時為什么客戶會端超時，而不是服務端返回RST（我印象里半打開服務端恢復后客戶端再發消息會返回RST，進而客戶端收到后會斷連?。?/li>
- 原文分享了一個issue：https://github.com/lettuce-io/lettuce-core/issues/1428
二、相關概念
- TCP半打開、半連接、半關閉：
- 半打開：TCP正常連接下，程序退出會主動斷連，但遇上斷電、斷網等場景，無法發出斷連消息，對方不知道連接已失效的狀態，不發消息的情況下，只能通過KeepAlive等機制探活超時后關閉
- 半連接：三次握手發起方一直不發起最后一次握手，連接會堆在syns queue時的狀態
- 半關閉：四次揮手時，發起方發送FIN，對方回復ACK后不發出FIN時的狀態
- KeepAlive常用的探活機制：啟用SO_KEEPALIVE進行探活，如果無法返回則認為對方宕機，后續可以采取重連或其他措施
- SO_KEEPALIVE：是否開啟KeepAlive
- TCP_KEEPIDLE：N秒內連接沒有任何網絡傳輸，就啟動KeepAlive機制
- TCP_KEEPINTVL：啟動KeepAlive時，每隔N秒發一次探活包
- TCP_KEEPCNT：N次探活包沒有響應，認為對方宕機
- 這里有個問題，KeepAlive啟動的場景是在一個正常響應后，就是說如果上一個數據包發送沒有響應，這時是超時重試階段，系統并不會啟動KeepAlive進行探活，只是簡單的認為卡了
-
tcp_retries2：Linux配置，默認15次代表tcp請求重試次數，重試的時間從200ms指數增長，最大120s，總時長15.4min，如果15.4min還是超時則斷開連接，重試次數和時間分布如下圖，這個問題之前竟然沒注意過！
tcp_retries2重試次數和時間 - 關于服務端閃斷后對客戶端連接的影響（半打開）：
- 如果客戶端一直沒有數據傳輸：這時客戶端無法知道服務端狀態，沒有其他機制影響會一直保持正常連接
- 如果客戶端發送了數據，服務端一直沒有恢復：這時因為對端沒有返回ACK所以默認連接會重試15次共15.4min后觸發超時斷開連接，即tcp_retries2
- 如果客戶端發送了數據，服務端已恢復，或重試過程中恢復：需要確認服務端這個連接還有沒有保持，如果服務端重啟，或服務端KeepAlive等機制導致連接已經丟棄，客戶端重試tcp_retries2后會超時斷開連接！如果服務端還保持連接則恢復正常通信
- 這里有個誤區！一直以為半打開服務端恢復服務后如果連接已經被清理，發送消息會回復RST！但其實會一直擱置導致超時。這個可能存在爭議，看過一些文章有寫會返回RST，但是問題排查和本地自測結果確實會tcp_retries2超時后斷連，可能問題就在這！
- TCP_USER_TIMEOUT：代表數據包N秒沒收到響應，觸發超時，配置后tcp_retries2會失效！
三、代碼調整：
- 按Git issue建議，減小Keepalive的檢測時間，同時增加TCP_USER_TIMEOUT機制
- TCP_USER_TIMEOUT負責請求超時處理，Keepalive負責空閑時心跳檢測
四、總結：
- 雖然配置能對應報錯，修改后應該也沒有復現Bug，但沒有保留現場無法抓包確認，最直接能確認問題是當時的服務端、客戶端的連接狀態，和服務端是否發出FIN包未到達客戶端，大概率是因為節點網絡問題導致整個節點全部半打開，其他未受影響。
五、后續：
- 正好同事遇到了這個問題，客戶端Jedis，使用Redis PubSub，并沒有出現超時，因為只是單純收消息并沒有發，發生問題時網絡原因斷網一段時間，因服務端Keepalive時間較短，客戶端Keepalive較長，網絡在服務端Keepalive內沒有恢復，服務端連接斷開，產生半打開，此后客戶端一直收不到消息，直到客戶端Keepalive生效，連接重連，符合上述推測
- 這個問題也可以發現，半打開導致的bug和Redis客戶端沒有太大關系，是TCP層面的邏輯，完全取決于Keepalive相關的配置
