高并發服務遇redis瓶頸引發time-wait事故
摘要
元旦期間 訂單業務線 告知 推送系統 無法正常收發消息，作為推送系統維護者的我正外面瀟灑，無法第一時間回去，直接讓 ops 幫忙重啟服務，一切好了起來，重啟果然是個大殺器。由于推送系統本身是分布式部署，消息有做各種的可靠性策略，所以重啟是不會丟失消息事件的。
事后通過日志分析有大量的 redis 的報錯，十分鐘內有 16w 次的錯誤。日志的錯誤是 connect: cannot assign requested address 。該錯誤不是推送服務內部及 redis 庫返回的 error，而是系統回饋的 errno 錯誤。
這個錯誤是由于無法申請可用地址引起的，也就是無法申請到可用的 socket。
話說，元旦當天在線數和訂單量確實大了不少，往常推送系統的長連接客戶端在 35w，這次峰值飆到 50w 左右, 集群共 6 個節點，其中有 4 個節點每個都抗了 9w+ 的長連接。另外，推送的消息量也隨之翻倍。
分析
下面是 kibana 日志的統計，出錯的時間區間里有近 16w 次的 redis 報錯。
下面是出問題節點的 TCP 連接狀況，可以看到 established 在 6w，而 time-wait 連接干到 2w 多個。
為什么會產生這么多 time-wait？誰主動關閉就就有 time-wait，但推送系統除了協議解析失敗之外，其余情況都不會主動 close 客戶端，哪怕是鑒權失敗和弱網絡客戶端寫緩沖爆滿，事后通過日志也確定了不是推送系統自身產生的 tw。
另外，linux 主機被 ops 交付時應該有做內核調優初始化的，在開啟 tw_reuse 參數后，time-wait 是可以復用的。難道是沒開啟 reuse？
查看 sysctl.conf 的內核參數得知，果然 tcp_tw_reuse 參數沒有打開，不能快速地復用還處在 time-wait 狀態的地址，只能等待 time-wait 的超時關閉，rfc 協議里規定等待 2 分鐘左右，開啟 tw_reuse可在 1s 后復用該地址。另外 ip_local_port_range 端口范圍也不大，縮短了可用的連接范圍。
- sysctl -a|egrep "tw_reuse|timestamp|local_port"
- net.ipv4.ip_local_port_range = 35768 60999
- net.ipv4.tcp_timestamps = 1
- net.ipv4.tcp_tw_reuse = 0
所以，由于沒有可用地址才爆出了 connect: cannot assign requested address 錯誤。
內在問題
追究問題
上面是表象問題，來查查為什么會有這么多的 time-wait ？再說一遍，通常哪一端主動 close fd，哪一端就會產生 time-wait。事后通過 netstat 得知 time-wait 連接基本是來自 redis 主機。
下面是推送代碼中的連接池配置，空閑連接池只有 50，最大可以 new 的連接可以到 500 個。這代表當有大量請求時，企圖先從 size 為 50 的連接池里獲取連接，如果拿不到連接則 new 一個新連接，連接用完了后需要歸還連接池，如果這時候連接池已經滿了，那么該連接會主動進行 close 關閉。
- MaxIdle = 50
- MaxActive = 500
- Wait = false
除此之外，還發現一個問題。有幾處 redis 的處理邏輯是異步的，比如每次收到心跳包都會 go 一個協程去更新 redis, 這也加劇了連接池的搶奪，改為同步代碼。這樣在一個連接上下文中同時只對一個 redis 連接操作。
解決方法
調大 golang redis client 的 maxIdle 連接池大小，避免了高下無空閑連接而新建連接和池子爆滿又不能歸還連接的尷尬場面。當 pool wait 為 true 時，意味著如果空閑池中沒有可用的連接，且當前已建立連接的連接數大于 MaxActive 最大空閑數，則一直阻塞等待其他人歸還連接。反之直接返回 “connection pool exhausted” 錯誤。
- MaxIdle = 300
- MaxActive = 400
- Wait = true
redis 的 qps 性能瓶頸
redis 的性能一直是大家所稱贊的，在不使用 redis 6.0 multi io thread 下，QPS 一般可以在 13w 左右，如果使用多指令和 pipeline 的話，可以干到 40w 的 OPS 命令數，當然 qps 還是在 12w-13w 左右。
Redis QPS 高低跟 redis 版本和 cpu hz、cache 存在正比關系
根據我的經驗，在內網環境下且已實例化連接對象，單條 redis 指令請求耗時通常在 0.2ms 左右，200us 已經夠快了，但為什么還會有大量因 redis client 連接池無空閑連接而建立新連接的情況？
通過 grafana 監控分析 redis 集群，發現有幾個節點 QPS 已經到了 Redis 單實例性能瓶頸，QPS 干到了近 15w 左右。難怪不能快速處理來自業務的 redis 請求。這個瓶頸必然會影響請求的時延。請求的時延都高了，連接池不能及時返回連接池，所以就造成了文章開頭說的問題。總之，業務流量的暴增引起了一系列問題。
發現問題，那么就要解決問題，redis 的 qps 優化方案有兩步：
- 擴容 redis 節點，遷移 slot 使其分擔流量
- 盡量把程序中 redis 的請求改成批量模式
增加節點容易，批量也容易。起初在優化推送系統時，已經把同一個邏輯中的 redis 操作改為批量模式了。但問題來了，很多的 redis 操作在不同的邏輯塊里面，沒法合成一個 pipeline。
然后做了進一步的優化，把不同邏輯中的 redis 請求合并到一個 pipeline 里，優點在于提高了 redis 的吞吐，減少了 socket 系統調用、網絡中斷開銷，缺點是增加了邏輯復雜度，使用 channal 管道做隊列及通知增加了 runtime 調度開銷，pipeline worker 觸發條件是滿足 3 個 command 或 5ms 超時，定時器采用分段的時間輪。
對比優化修改前，cpu開銷減少了 3% 左右，壓測下redis qps平均降了 3w 左右差值，最多可以降到 7w 左右，當然概率上消息的時延會高了幾個ms。
實現的邏輯參考下圖，調用方把redis command和接收結果的chan推送到任務隊列中，然后由一個worker去消費，worker組裝多個redis cmd為pipeline，向redis發起請求并拿回結果，拆解結果集后，給每個命令對應的結果chan推送結果。調用方在推送任務到隊列后，就一直監聽傳輸結果的chan。
這個方案來自我在上家公司做推送系統的經驗，有興趣的朋友可以看看 PPT，內涵不少golang高并發經驗。
總結
推送系統設計之初是預計 20w 的長連接數，穩定后再無優化調整，也一直穩定跑在線上。后面隨著業務的暴漲，長連接數也一直跟著暴漲，現在日常穩定在 35w，出問題時暴到 50w，我們沒有因為業務暴增進行整條鏈路壓測及優化。
話說，如果對推送系統平時多上點心也不至于出這個問題。我曾經開發過相對高規格的推送系統，而現在公司的推送系統我是后接手的，由于它的架子一般，但業務性又太強，看著腦仁疼，所以就沒有推倒來重構。一直是在這個架子上添添補補，做了一些常規的性能優化。嗯，看來不能掉以輕心，免得績效離我遠去。
