這周本來是要寫一篇Dubbo源碼分析的，被突發(fā)事件耽擱了，下周有時間再補上。

這周，筆者經(jīng)歷了一次服務(wù)雪崩。服務(wù)雪崩，聽到這個詞就能想到問題的嚴(yán)重性。是的，整個項目，整條業(yè)務(wù)線都掛了，從該業(yè)務(wù)線延伸出來的下游業(yè)務(wù)線也跟著涼了。筆者是連續(xù)三天兩夜的忙著處理問題，加起來睡眠時間不足5小時，今天才得以睡個好覺。但事故之后還有很多問題等著去處理。

其實這一天的到來我是有意料到的，但我以為會是數(shù)據(jù)量上升導(dǎo)致，實際卻是并發(fā)量先上升，而嚴(yán)重程度超出我的預(yù)料。問題出現(xiàn)那天，我們還在進(jìn)行每周的技術(shù)分享會，結(jié)果運營推開會議室的大門傳來噩耗，頓時技術(shù)分享會變成了問題排查討論會，場面像極了一起加班解決Bug。

在一個處理用戶點擊廣告的高并發(fā)服務(wù)上找到了問題。看到服務(wù)打印的日記后我完全蒙了，全是jedis讀超時，Read time out！一直用的是亞馬遜的Redis服務(wù)，很難想象Jedis會讀超時。

看了服務(wù)的負(fù)載均衡統(tǒng)計，發(fā)現(xiàn)并發(fā)增長了一倍，從每分鐘3到4萬的請求數(shù)，增長到8.6萬，很顯然，是并發(fā)翻倍導(dǎo)致的服務(wù)雪崩。

服務(wù)的部署：

處理廣告點擊的服務(wù)：2臺2核8g的實例，每臺部署一個節(jié)點(服務(wù))。下文統(tǒng)稱服務(wù)A

規(guī)則匹配服務(wù)(Rpc遠(yuǎn)程調(diào)用服務(wù)提供者)：2個節(jié)點，2臺2核4g實例。下文統(tǒng)稱服務(wù)B

還有其它的服務(wù)提供者，但不是影響本次服務(wù)雪崩的兇手，這里就不列舉了。

從日記可以看出的問題：

一是遠(yuǎn)程rpc調(diào)用大量超時，我配置的dubbo參數(shù)是，每個接口的超時時間都是3秒。服務(wù)提供者接口的實現(xiàn)都是緩存級別的操作，3秒的超時理論上除了網(wǎng)絡(luò)問題，調(diào)用不應(yīng)該會超過這個值。在服務(wù)消費端，我配置每個接口與服務(wù)端保持10個長連接，避免共享一個長連接導(dǎo)致應(yīng)用層數(shù)據(jù)包排隊發(fā)送和處理接收。

二是剛說的Jedis讀操作超時，Jedis我配置每個服務(wù)節(jié)點200個最小連接數(shù)的連接池，這是根據(jù)netty工作線程數(shù)配置的，即讀寫操作就算200個線程并發(fā)執(zhí)行，也能為每個線程分配一個連接。這是我設(shè)置Jedis連接池連接數(shù)的依據(jù)。

三是文件句柄數(shù)達(dá)到上線。SocketChannel套接字會占用一個文件句柄，有多少個客戶端連接就占用多少個文件句柄。我在服務(wù)的啟動腳本上為每個進(jìn)程配置102400的最大文件打開數(shù)，理論上目前不會達(dá)到這個值。服務(wù)A底層用的是基于Netty實現(xiàn)的http服務(wù)引擎，沒有限制最大連接數(shù)。

所以，解決服務(wù)雪崩問題就是要圍繞這三個問題出發(fā)。

第一次是懷疑redis服務(wù)扛不住這么大的并發(fā)請求。估算廣告的一次點擊需要執(zhí)行20次get操作從redis獲取數(shù)據(jù)，那么每分鐘8w并發(fā)，就需要執(zhí)行160w次get請求，而redis除了本文提到的服務(wù)A和服務(wù)B用到外，還有其它兩個并發(fā)量高的服務(wù)在用，保守估計，redis每分鐘需要承受300w的讀寫請求。轉(zhuǎn)為每秒就是5w的請求，與理論值redis每秒可以處理超過 10萬次讀寫操作已經(jīng)過半。

由于歷史原因，redis使用的還是2.x版本的，用的一主一從，jedis配置連接池是讀寫分離的連接池，也就是寫請求打到主節(jié)點，讀請求打到從節(jié)點，每秒接近5w讀請求只有一個redis從節(jié)點處理，非常的吃力。所以我們將redis升級到4.x版本，并由主從集群改為分布式集群，兩主無從。別問兩主無從是怎么做到的，我也不懂，只有亞馬遜清楚。

Redis升級后，理論上，兩個主節(jié)點，分槽位后請求會平攤到兩個節(jié)點上，性能會好很多。但好景不長，服務(wù)重新上線一個小時不到，并發(fā)又突增到了六七萬每分鐘，這次是大量的RPC遠(yuǎn)程調(diào)用超時，已經(jīng)沒有jedis的讀超時Read time out了，相比之前好了點，至少不用再給Redis加節(jié)點。

這次的事故是并發(fā)量超過臨界值，超過redis的實際最大qps(跟存儲的數(shù)據(jù)結(jié)構(gòu)和數(shù)量有關(guān))，雖然升級后沒有Read time out! 但Jedis的Get讀操作還是很耗時，這才是罪魁禍?zhǔn)住edis的命令耗時與Jedis的讀操作Read time out不同。

redis執(zhí)行一條命令的過程是：

1、接收客戶端請求

2、進(jìn)入隊列等待執(zhí)行

3、執(zhí)行命令

4、響應(yīng)結(jié)果給客戶端

由于redis執(zhí)行命令是單線程的，所以命令到達(dá)服務(wù)端后不是立即執(zhí)行，而是進(jìn)入隊列等待。redis慢查詢?nèi)沼浻涗泂lowlog get的是執(zhí)行命令的耗時，對應(yīng)步驟3，執(zhí)行命令耗時是根據(jù)key去找到數(shù)據(jù)所在的內(nèi)存地址這段時間的耗時，所以這對于key-value字符串類型的命令而言，并不會因為value的大小而導(dǎo)致命令耗時長。

為驗證這個觀點，我進(jìn)行了簡單的測試。

分別寫入四個key，每個key對應(yīng)的value長度都不等，一個比一個長。再來看下兩組查詢?nèi)沼洝Ｏ韧ㄟ^CONFIG SET slowlog-log-slower-than 0命令，讓每條命令都記錄耗時。

key_4的value長度比key_3的長兩倍，但get耗時比key_3少，而key_1的value長度比key_2短，但耗時比key_2長。

第二組數(shù)據(jù)也是一樣的，跟value的值大小無關(guān)。所以可以排除項目中因value長度過長導(dǎo)致的slowlog記錄到慢查詢問題。慢操作應(yīng)該是set、hset、hmset、hget、hgetall等命令耗時比較長導(dǎo)致。

而Jedis的Read time out則是包括1、2、3、4步驟，從命令的發(fā)出到接收完成Redis服務(wù)端的響應(yīng)結(jié)果，超時原因有兩大原因：

1、redis的并發(fā)量增加，導(dǎo)致命令等待隊列過長，等待時間長

2、get請求讀取的數(shù)據(jù)量大，數(shù)據(jù)傳輸時間長

所以將Redis從一主一從改為兩主之后，導(dǎo)致Jedis的Read time out的原因一有所緩解，分?jǐn)偭瞬糠謮毫Α５窃?還是存在，耗時依然是問題。

Jedis的get耗時長導(dǎo)致服務(wù)B接口執(zhí)行耗時超過設(shè)置的3s。由于dubbo消費端超時放棄請求，但是請求已經(jīng)發(fā)出，就算消費端取消，提供者無法感知服務(wù)端超時放棄了，還是要執(zhí)行完一次調(diào)用的業(yè)務(wù)邏輯，就像說出去的話收不回來一樣。

由于dubbo有重試機制，默認(rèn)會重試兩次，所以并發(fā)8w對于服務(wù)b而言，就變成了并發(fā)24w。最后導(dǎo)致業(yè)務(wù)線程池一直被占用狀態(tài)，RPC遠(yuǎn)程調(diào)用又多出了一個異常，就是遠(yuǎn)程服務(wù)線程池已滿，直接響應(yīng)失敗。

問題最終還是要回到Redis上，就是key對應(yīng)的value太大，傳輸耗時，最終業(yè)務(wù)代碼拿到value后將value分割成數(shù)組，判斷請求參數(shù)是否在數(shù)組中，非常耗時，就會導(dǎo)致服務(wù)B接口耗時超過3s，從而拖垮整個服務(wù)。

模擬服務(wù)B接口做的事情，業(yè)務(wù)代碼(1)。

/** * @author wujiuye?*?@version 1.0 on 2019/10/20?{描述：} */public class Match {    static class Task implements Runnable {        private String value;        public Task(String value) {            this.value = value;        }        @Override        public void run() {            for (; ; ) {                // 模擬jedis get耗時                try {                    Thread.sleep(10);                } catch (InterruptedException e) {                    e.printStackTrace();                }                // =====> 實際業(yè)務(wù)代碼                long start = System.currentTimeMillis();                List ids = Arrays.stream(value.split(",")).collect(Collectors.toList());                boolean exist = ids.contains("4029000");                // ====> 輸出結(jié)果，耗時171ms .                System.out.println("exist:" + exist + ",time:" + (System.currentTimeMillis() - start));            }        }    }    ;    public static void main(String[] args) {        // ====> 模擬業(yè)務(wù)場景，從緩存中獲取到的字符串        StringBuilder value = new StringBuilder();        for (int i = 4000000; i <= 4029000; i++) {            value.append(String.valueOf(i)).append(",");        }        String strValue = value.toString();        System.out.println(strValue.length());        for (int i = 0; i < 200; i++) {            new Thread(new Task(strValue)).start();        }????}}

這段代碼很簡單，就是模擬高并發(fā)，把200個業(yè)務(wù)線程全部耗盡的場景下，一個簡單的判斷元素是否存在的業(yè)務(wù)邏輯執(zhí)行需要多長時間。把這段代碼跑一遍，你會發(fā)現(xiàn)很多執(zhí)行耗時超過1500ms，再加上Jedis讀取到數(shù)據(jù)的耗時，直接導(dǎo)致接口執(zhí)行耗時超過3000ms。

這段代碼不僅耗時，還很耗內(nèi)存，沒錯，就是這個Bug了。改進(jìn)就是將id拼接成字符串的存儲方式改為hash存儲，直接hget方式判斷一個元素是否存在，不需要將這么大的數(shù)據(jù)讀取到本地，即避免了網(wǎng)絡(luò)傳輸消耗，也優(yōu)化了接口的執(zhí)行速度。

由于并發(fā)量的增長，導(dǎo)致redis讀并發(fā)上升，Jedis的get耗時長，加上業(yè)務(wù)代碼的缺陷，導(dǎo)致服務(wù)B接口耗時長，從而導(dǎo)致服務(wù)A遠(yuǎn)程RPC調(diào)用超時，導(dǎo)致dubbo超時重試，導(dǎo)致服務(wù)B并發(fā)乘3，再導(dǎo)致服務(wù)B業(yè)務(wù)線程池全是工作狀態(tài)以及Redis并發(fā)又增加，導(dǎo)致服務(wù)A調(diào)用異常。正是這種連環(huán)效應(yīng)導(dǎo)致服務(wù)雪崩。

最后優(yōu)化分三步

一是優(yōu)化數(shù)據(jù)的redis緩存的結(jié)構(gòu)，剛也提到，由大量id拼接成字符串的key-value改成hash結(jié)構(gòu)緩存，請求判斷某個id是否在緩存中用hget，除了能降低redis的大value傳輸耗時，也能將判斷一個元素是否存在的時間復(fù)雜度從O(n)變?yōu)镺(1)，接口耗時降低，消除RPC遠(yuǎn)程調(diào)用超時。

二是業(yè)務(wù)邏輯優(yōu)化，降低Redis并發(fā)。將服務(wù)B由一個服務(wù)拆分成兩個服務(wù)。這里就不多說了。

三是Dubbo調(diào)優(yōu)，將Dubbo的重試次數(shù)改為0，失敗直接放棄當(dāng)前的廣告點擊請求。為避免突發(fā)性的并發(fā)量上升，導(dǎo)致服務(wù)雪崩，為服務(wù)提供者加入熔斷器，估算服務(wù)所能承受的最大QPS，當(dāng)服務(wù)達(dá)到臨界值時，放棄處理遠(yuǎn)程RPC調(diào)用。

(我用的是Sentinel，官方文檔傳送門：

https://github.com/alibaba/Sentinel/wiki/%E6%8E%A7%E5%88%B6%E5%8F%B0)

(Sentinel控制臺)

所以，緩存并不是簡單的Get，Set就行了，Redis提供這么多的數(shù)據(jù)結(jié)構(gòu)的支持要用好，結(jié)合業(yè)務(wù)邏輯優(yōu)化緩存結(jié)構(gòu)。避免高并發(fā)接口讀取的緩存value過長，導(dǎo)致數(shù)據(jù)傳輸耗時。同時，Redis的特性也要清楚，分布式集群相比單一主從集群的優(yōu)點。反省img。

經(jīng)過兩次的項目重構(gòu)，項目已經(jīng)是分布式微服務(wù)架構(gòu)，同時業(yè)務(wù)的合理劃分讓各個服務(wù)之間完美解耦，每個服務(wù)內(nèi)部的實現(xiàn)合理利用設(shè)計模式，完成業(yè)務(wù)的高內(nèi)聚低耦合，這是一次非常大的改進(jìn)，但還是有還多歷史遺留的問題不能很好的解決。同時，分布式也帶來了很多問題，總之，有利必有弊。

有時候就需要這樣，被項目推著往前走。在未發(fā)生該事故之前，我花一個月時間也沒想出困擾我的兩大難題，是這次的事故，讓我從一個短暫的夜晚找出答案，一個通宵讓我想通很多問題。

對于本次服務(wù)雪崩帶來的影響，我只能深感抱歉！說實話，我已經(jīng)厭倦了這種賣力不討好的事情。

總結(jié)

以上是生活随笔為你收集整理的ssl 接收到一个超出最大准许长度的记录_我所经历的一次Dubbo服务雪崩，这是一个漫长的故事...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。