redis連接數爆掉

回到首頁☞

1 問題描述

研發環境平穩運行，每天有幾千vm創建，那關主機越來越多。
當增加到43W主機的時候出現了問題，部分請求失敗，請求慢。

2、問題定位及處理

1、進入openresty OS 查看網絡狀態

netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}'

LAST_ACK 5 （正在等待處理的請求數）
SYN_RECV 30
ESTABLISHED 12524（正常數據傳輸狀態）
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 35854 （處理完畢，等待超時結束的請求數）

大約如上，發現大量併發和大量等待超時結束。

openresty主要做了兩件事，上報心跳和獲取任務，都是lua+redis實現。

lua nginx配置是access_by_lua，嘗試改爲content_by_lua。鏈接下降了。

2、查看資源使用情況
top -->1
發現nginx 使用了4個cpu邏輯單元基本是100%
但是通過top看 cpu有8個邏輯內核，所以nginx實例設置爲8
./nginx -s stop
./nginx
重啓nginx 後，壓力所有下降。
單邊curl，請求明顯不在卡了。

3、查看lua運行日誌。

發現大量timed out，鏈接redis超時。

4、查看redis 運行監控
鏈接併發數像高血壓一樣持續飆升。
雲上redis是三主三備的資源，竟然併發數持續高升到 15000+，而redis平臺給提供的併發默認配置爲10000.
5、平臺穩定性是大問題，緊急聯繫redis平臺。
redis平臺最大鏈接給擴容到 30000，重啓redis 服務器，當時就完美無缺。
高興沒20分鐘，redis再次報表在25000+的併發量。

計算了一下：43000+/30 怎麼都有這麼大的併發，怎麼玩？

6、能通過資源解決的問題絕對不糾結技術
重新申請一套redis服務 6+6 10000鏈接
修改所有執行引擎 執行任務相關鏈路，緊急部署，心跳和任務做分離，各自用一套redis實例。

 local config = {
                name = "test",
                serv_list = {
                    {ip="10.1.0.15", port = 6389},
                    {ip="10.1.2.15", port = 6389},
                    {ip="10.1.2.133", port = 6389},
                    {ip="10.1.3.154", port = 6389},
                   {ip="10.1.11.125", port = 6389},
                    {ip="10.1.123.125", port = 6389},
                },
            }
            local redis_cluster = require "resty.rediscluster"
            local red = redis_cluster:new(config)

寫法就是如上，lua這塊的。

緊急走流程變更上線。

上報心跳redis 連接數穩定到了300+
執行任務鏈路的redis 連接數穩定到了 1000~1200

7、最後遺留的ELB問題
OS定期請求進入nginx是通過ELB，單邊測試毫無問題，1S內處理完請求，但是通過ELB進入系統卻多次出現404.
這個知識和權限範圍外，只有ELB的團隊排查處理了。

3、小結

1、資源能解決的問題就用資源解決。
2、redis也不是無敵的
3、希望未來能支撐到100萬OS的自動化。

回到首頁☞