?

Bug影響：Dubbo服務(wù)提供者出現(xiàn)無法獲取Dubbo服務(wù)處理線程異常，后端DB爆出拿不到數(shù)據(jù)庫連接池，導(dǎo)致前端響應(yīng)時(shí)間異常飆高，系統(tǒng)處理能力下降，核心基礎(chǔ)服務(wù)無法提供正常服務(wù)。

?Bug發(fā)現(xiàn)過程：

?線 上，對于高并發(fā)的服務(wù)化接口應(yīng)用，時(shí)常會(huì)出現(xiàn)Dubbo連接池爆滿情況，通常，我們理所應(yīng)當(dāng)?shù)恼J(rèn)為，這是客戶端并發(fā)連接過高所致，一方面調(diào)整連接池大小， 一方面考慮去增加服務(wù)接口的機(jī)器，當(dāng)然也會(huì)考慮去優(yōu)化服務(wù)接口的應(yīng)用。很自然的，當(dāng)我們在線上壓測一個(gè)營銷頁面（為大促服務(wù)，具備高并發(fā)）時(shí)，我們遇到了 這種情況。而通過不斷的深入研究，我發(fā)現(xiàn)了一個(gè)特別的情況。

場景描述：

?

壓力從Jmeter壓至前端web應(yīng)用marketingfront，場景是批量獲取30個(gè)產(chǎn)品的信息。wsproductreadserver有一個(gè)批量接口，會(huì)循環(huán)從tair中獲取產(chǎn)品信息，若緩存不存在，則命中db。

壓測后有兩個(gè)現(xiàn)象：

1）Dubbo的服務(wù)端爆出大量連接拿不到的異常，還伴隨著無法獲取數(shù)據(jù)庫連接池的情況

2)Dubbo Consumer端有大量的Dubbo超時(shí)和重試的異常，且重試3次后，均失敗。

3)Dubbo Consumer端的最大并發(fā)時(shí)91個(gè)

Dubbo Provider端的最大并發(fā)卻是600個(gè)，而服務(wù)端配置的dubbo最大線程數(shù)即為600

這個(gè)時(shí)候，出于性能測試的警覺性，發(fā)現(xiàn)這兩個(gè)并發(fā)數(shù)極為不妥。

按照正常的請求模式，DubboConsumer和DubboProvider展示出來的并發(fā)應(yīng)該是一致的。此處為何會(huì)出現(xiàn)服務(wù)端的并發(fā)數(shù)被放大6倍，甚至有可能不止6倍，因?yàn)榉?wù)端的dubbo連接數(shù)限制就是600。

此處開始發(fā)揮性能測試各種大膽猜想：

1）是否是因?yàn)榉?wù)端再dubboServerHandle處理請求時(shí)，開啟了多線程，而這塊兒的多線程會(huì)累計(jì)到Dubbo的連接上，dragoon采集的這個(gè)數(shù)據(jù)可以真實(shí)的反應(yīng)目前應(yīng)用活動(dòng)的線程對系統(tǒng)的壓力情況；

2）壓測環(huán)境不純潔？我的小伙伴們在偷偷和我一起壓測？（這個(gè)被我生生排除了，性能測試基本環(huán)境還是要保持獨(dú)立性）

3）是否是因?yàn)槌瑫r(shí)所致？這里超時(shí)會(huì)重試3次，那么順其自然的想，并發(fā)有可能最多會(huì)被放大到3倍，3*91=273<<600….還是不止3倍？

有了猜想，就得小心求證！

首先通過和dubbo開發(fā)人員 【草谷】分析，Dubbo連接數(shù)爆滿的原因，猜想1被否決，Dubbo服務(wù)端連接池是計(jì)數(shù)DubboServerHandle個(gè)數(shù)的業(yè)務(wù)是否采用多線程無關(guān)。 通過在壓測時(shí)，Dump provider端的線程數(shù)，也證明了這個(gè)。

?

那么，可能還是和超時(shí)有很大關(guān)系。 再觀察wsproductreadserver接口的處理時(shí)間分布情況：

?

?從RT的分布來看。基本上78.5%的響應(yīng)時(shí)間是超過1s的。那么這個(gè)接口方法的dubbo超時(shí)時(shí)間是500ms，此時(shí)dubbo的重試機(jī)制會(huì)帶來怎樣的雪崩效應(yīng)呢？

如果按照上圖，雖然客戶端只有1個(gè)并發(fā)在做操作，但是由于服務(wù)端執(zhí)行十分耗時(shí)，每個(gè)請求的執(zhí)行RT遠(yuǎn)遠(yuǎn)超過了超時(shí)時(shí)間500ms，此時(shí)服務(wù)端的最大并發(fā)會(huì)有多少呢? 和服務(wù)端處理的響應(yīng)時(shí)間有特比特別大的關(guān)系。服務(wù)端處理時(shí)間變長，但是如果超時(shí)，客戶端的阻塞時(shí)間卻只有可憐的500ms，超過500ms，新一輪壓力又將發(fā)起。 上圖可直接看到的并發(fā)是8個(gè)，如果服務(wù)端RT再長些，那么并發(fā)可能還會(huì)再大些！ 這也是為什么從marketingfront consumer的dragoon監(jiān)控來看，只有90個(gè)并發(fā)。但是到服務(wù)端，卻導(dǎo)致dubbo連接池爆掉的直接原因。 查看了wsproductreadserver的堆棧，600個(gè)dubboServerHandle大部分都在做數(shù)據(jù)庫的讀取和數(shù)據(jù)庫連接獲取以及tair的操作。 所以，為什么Dubbo服務(wù)端的連接池會(huì)爆掉？很有可能就是因?yàn)槟愕姆?wù)接口，在高并發(fā)下的大部分RT分布已經(jīng)超過了你的Dubbo設(shè)置的超時(shí)時(shí)間！這將直接導(dǎo)致Dubbo的重試機(jī)制會(huì)不斷放大你的服務(wù)端請求并發(fā)。 所 以如果，你在線上曾經(jīng)遇到過類似場景，您可以采取去除Dubbo的重試機(jī)器，并且合理的設(shè)置Dubbo的超時(shí)時(shí)間。目前國際站的服務(wù)中心，已經(jīng)開始去除 Dubbo的重試機(jī)制。當(dāng)然Dubbo的重試機(jī)制其實(shí)是非常好的QOS保證，它的路由機(jī)制，是會(huì)幫你把超時(shí)的請求路由到其他機(jī)器上，而不是本機(jī)嘗試，所以 dubbo的重試機(jī)器也能一定程度的保證服務(wù)的質(zhì)量。但是請一定要綜合線上的訪問情況，給出綜合的評估。 ————等等等，別著急，我們似乎又忽略了一些細(xì)節(jié)，元芳，你怎么看？———————— 我們重新回顧剛才的業(yè)務(wù)流程架構(gòu)，wsproductReadserver層有DB和tair兩級存儲。那么對于同樣接口為什么服務(wù)化的接口RT如此之差，按照前面提到的架構(gòu)，包含tair緩存，怎么還會(huì)有數(shù)據(jù)庫連接獲取不到的情況？ ?接續(xù)深入追蹤，將問題暴露和開發(fā)討論，他們拿出tair ?可以看到，客戶端提交批量查詢30個(gè)產(chǎn)品的產(chǎn)品信息。在服務(wù)端，有一個(gè)緩存模塊，緩存的key是產(chǎn)品的ID。當(dāng)產(chǎn)品命中tair時(shí)，則直接返回，若不命中，那么回去db中取數(shù)，再放入緩存中。

這里可以發(fā)現(xiàn)一個(gè)潛在的性能問題：

客 戶端提交30個(gè)產(chǎn)品的查詢請求，而服務(wù)端，則通過for循環(huán)和tair交互，所以這個(gè)接口在通常情況下的性能估計(jì)也得超過60-100ms。如果不是30 個(gè)產(chǎn)品，而是50或者100，那么這個(gè)接口的性能將會(huì)衰減的非常厲害！（這純屬性能測試的yy，當(dāng)然這個(gè)暫時(shí)還不是我們本次關(guān)注的主要原因）

那么如此的架構(gòu)，請求打在db上的可能性是比較小的， 由緩存命中率來保證。從線上真實(shí)的監(jiān)控?cái)?shù)據(jù)來看，tair的命中率在70%，應(yīng)該說還不錯(cuò)，為什么在我們的壓測場景，DB的壓力確是如此兇殘，甚至導(dǎo)致db的連接池?zé)o法獲取呢？

所以性能驗(yàn)證場景就呼之欲出了：

場景：準(zhǔn)備30個(gè)產(chǎn)品ID，保持不變，這樣最多只會(huì)第一次會(huì)去訪問DB，并將數(shù)據(jù)存入緩存，后面將會(huì)直接命中緩存，db就在后面喝喝茶好了！

但是從測試結(jié)果來看，有兩點(diǎn)可以觀察到： 1） tair是存在命中的，否則查詢db的總次數(shù)應(yīng)該是30*66812 2） 查詢db的次數(shù)大概是調(diào)用次數(shù)的2倍。從數(shù)據(jù)比例可以明顯的看出，可能有2個(gè)產(chǎn)品一直沒命中緩存。 3） 但是這個(gè)數(shù)據(jù)也讓我們奇怪，如果緩存開始工作，為什么總是有一些產(chǎn)品未進(jìn)入緩存？ 于是開始檢查這30個(gè)產(chǎn)品到底有哪幾個(gè)沒有存入緩存。 通 過開發(fā)Debug預(yù)發(fā)布環(huán)境代碼，最終發(fā)現(xiàn)，這兩個(gè)產(chǎn)品竟然已經(jīng)被用戶移到垃圾箱了。而通過和李浩和躍波溝通SellerCoponList的業(yè)務(wù)來 看，DA推送過來的產(chǎn)品是存在被用戶移除的可能性。因而，每次這兩個(gè)數(shù)據(jù)的查詢，由于數(shù)據(jù)庫查詢不到記錄，tair也沒有存儲相關(guān)記錄，導(dǎo)致這些查詢都將 經(jīng)過數(shù)據(jù)庫。數(shù)據(jù)庫壓力原因也找到了。 ? ?但是問題還沒有結(jié)束，這似乎只像是冰山表面，我們希望能夠鳥瞰整個(gè)冰山！ ?細(xì)細(xì)品味這個(gè)問題的最終性能表象，這是一種變向擊穿緩存的做法啊！也就是具備一定的通用性。如果接口始終傳入數(shù)據(jù)庫和緩存都不可能存在的數(shù)據(jù)，那么每次的訪問都就落到db上，導(dǎo)致緩存變相擊穿，這個(gè)現(xiàn)象很有意思！ ? ?目前有一種解決方案，就是Null Object Pattern，將數(shù)據(jù)庫不存在的記錄也記錄到緩存中，但是value為NULL，使得緩存可以有效的攔截。由于數(shù)據(jù)的超時(shí)時(shí)間是10min，所以如果數(shù)據(jù)有所改動(dòng)，也可以接受。 ? ? 我相信這只是一種方案，可能還會(huì)有其他方案，但是這種變向的緩存擊穿卻讓我很興奮。回過頭來，如果讓我自己去實(shí)現(xiàn)這樣的緩存機(jī)制，數(shù)據(jù)庫和緩存都不存在的 數(shù)據(jù)場景很容易被忽略，并且這個(gè)對于業(yè)務(wù)確實(shí)也不會(huì)有影響。在線上存在大量熱點(diǎn)數(shù)據(jù)情況下，這樣的機(jī)制，往往并不會(huì)暴露性能問題。巧合的是，特定的場景， 性能卻會(huì)出現(xiàn)很大的偏差，這考驗(yàn)的既是性能測試工程師的功力，也考驗(yàn)的是架構(gòu)的功力！

?Bug解決辦法：

其實(shí)這過程中不僅僅有一些方法論，也有一些是性能測試經(jīng)驗(yàn)的功底，更重要的是產(chǎn)出了一些通用性的性能問題解決方案，以及部分參數(shù)和技術(shù)方案的設(shè)計(jì)對系統(tǒng)架構(gòu)的影響。?

1）對于核心的服務(wù)中心，去除dubbo超時(shí)重試機(jī)制，并重新評估設(shè)置超時(shí)時(shí)間。

?2）對于存在tair或者其他中間件緩存產(chǎn)品，對NULL數(shù)據(jù)進(jìn)行緩存，防止出現(xiàn)緩存的變相擊穿問題

?

?GBA傳承：

?

?個(gè)人感受：

?1）性能調(diào)優(yōu)和診斷是一個(gè)不斷挖掘的過程，不放過一個(gè)細(xì)節(jié)點(diǎn)，大膽猜想，小心求證

?2）敢于質(zhì)疑開發(fā)的建議和解決方案，提出自己的思路，并求證

?3）勇于專研。性能調(diào)優(yōu)就像追求自己心儀的女孩，有時(shí)努力了很久卻沒有任何結(jié)果，但是心動(dòng)的感覺卻是一生僅有的。

轉(zhuǎn)載于:https://www.cnblogs.com/austinspark-jessylu/p/7793403.html

總結(jié)

以上是生活随笔為你收集整理的Dubbo超时机制导致的雪崩连接的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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