問題描述
部署在AKS中的應用，連線Redis高頻率出現timeout問題
問題解答
檢視Redis狀態，沒有任何異常，服務沒有更新，Service Load， CPU， Memory， Connect等指標均正常。在排除Redis端問題後，轉向了AKS中。
開始調查AKS的網路狀態。最終發現每次Redis客戶端出現超時問題時，幾乎都對應了AKS NAT Gateway的更新事件，而Redis服務端沒有任何異常。因此，超時問題很可能是由於NAT Gateway更新事件導致TCP連線被重置。
NAT更新原理: 在NAT Gateway的底層元件更新初期，被更新的內部例項將不會接受新的連線請求。在接下來的更新時間裡，所有傳入的資料包都將收到TCP RST（重置）訊息作為響應。而後存量連線被清空，例項就會進入更新流程。此操作確保在更新過程中，客戶端可以自動與其他未更新例項重新建立連線，從而儘量減少對業務的影響。
如何監控NAT更新: 可以透過NAT Gateway的Datapath Availability的指標來監控NAT閘道器是否發生了更新。在更新期間NAT Gateway的Datapath Availability會略微下降至98%及以下， 這可以作為判斷維護狀態的一個參考 : Azure NAT 閘道器的指標和警報 - Azure NAT Gateway | Microsoft Learn
面對如此情況，可作如下調整：
- Redis設定較短的超時時間，這樣可以更快地在客戶端層面重新建立連線，同時，負面效果是提高了超時報錯的機率。對於高操作頻率的Redis，較短的超時時間依然是一個比較好的方案。
- 可以將AKS 所在的Linux系統中的net.ipv4.tcp_retries2引數修改得更小，使TCP底層連線更快地重連。https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-best-practices-connection#tcp-settings-for-linux-hosted-client-applications
- 可以嘗試讓Redis客戶端建立更多連線數量，透過分散的出站連線，減少NAT Gateway例項更新對客戶端連線的影響。