[[398180]]

前言

分庫分表中間件在我們一年多的錘煉下，基本解決了可用性和高性能的問題(只能說基本，肯定還有隱藏的坑要填)，問題自然而然的就聚焦于高可用。本文就闡述了我們在這方面做出的一些工作。

哪些高可用的問題

作為一個無狀態的中間件，高可用問題并沒有那么困難。但是盡量減少不可用期間的流量損失，還是需要一定的工作的。這些流量損失主要分布在:

• (1)某臺中間件所在的物理機突然宕機。
• (2)中間件的升級和發布。

由于我們的中間件是作為數據庫的代理提供給應用的,即應用把我們的中間件當做數據庫，如下圖所示:

所以出現上述問題后，業務上很難通過重試等操作去屏蔽這些影響。這就勢必需要我們在底層做一些操作，能夠自動的感知中間件的狀態從而有效避免流量的損失。

中間件所在物理機宕機的情況

物理機宕機其實是一種常見現象，這時候應用一瞬間就沒了響應。那么跑在上面的sql肯定也是失敗了的(準確來說是未知狀態，除非重新查詢后端數據庫，應用無法得知準確的狀態)。這部分流量我們肯定是無法挽救。我們所做的是在client端(Druid數據源)能夠快速的發現并剔除宕機的中間件節點。

發現并剔除不可用節點

通過心跳去發現不可用節點

自然而然的我們通過心跳來探查后端中間件的存活狀態。我們通過定時創建一個新連接ping(mysql的ping)一下然后立馬關閉來做心跳(這種做法便于我們區分正常流量和心跳流量，如果通過保持一個連接然后一直發送類似select ‘1’的sql這種方式的話區分流量會稍微麻煩點)。

為了防止網絡抖動造成的偶發性connect失敗，我們在三次connect都失敗后才判定某臺中間件處于不可用狀態。而這三次的探活卻延長了錯誤感知時間，所以我們三次connect的時間間隔是指數級衰減的，如下圖所示:

為何不在第一次connect失敗后，連續發送兩次connect呢?可能考慮到網絡的抖動可能會有一個時間窗口，如果在時間窗口內連續發了3次，出了這個時間窗口網絡又okay了，那么會錯誤的發現后端某節點不可用了,所以我們就做了指數級衰減的折衷。

通過錯誤計數去發現不可用節點

上述的心跳感知始終有一個時間窗口，當流量很大的時候，在這個時間窗口內使用這個不可用節點的都會失敗,所以我們可以使用錯誤計數去輔助不可用節點的感知(當然這個手段的實現還在計劃中)。

這邊有一個注意的點是，只能通過創建連接異常來計數，并不能通過read timeout之類的來計算。原因是，read timeout異?？赡苁锹齭ql或者后端數據庫的問題導致，只有創建連接異常才能確定是中間件的問題(connection closed也可能是后端關閉了這個連接,并不代表整體不可用),如下圖所示:

一個請求使用若干個連接導致的問題

由于我們需要保證事務盡可能小，所以在一個請求里面多條sql并不使用同一個連接。在非事務(auto-commit)情況下，運行多少條sql就從連接池里面取出多少連接，并放回。保證事務小是非常重要的，但是這在中間件宕機的時候會導致一些問題，如下圖所示:

如上圖所示，在故障發現窗口期中(即還沒有確定某臺中間件不可用時)，數據源是隨機選擇連接的。而這個連接就有一定1/N(N為中間件個數)的概率命中不可用中間件導致一條sql失敗進而導致整個請求失敗。我們做一個計算：

假設N為8,一個請求有20條sql,

那么在這個期間每個請求失敗的概率就為(1-(7/8)的20次方)=0.93,

即有93%的概率會失敗!

更為甚者，整個應用集群都會經歷這個階段，即每臺應用都有93%的概率失敗。

一臺中間件宕機導致整個服務在十幾秒內基本所有請求基本都失敗，這是不可忍受的。

采用sticky數據源解決問題

由于我們不能瞬間發現并確認中間件不可用，所以這個故障發現窗口肯定存在(當然，錯誤計數法會在很大程度上縮短發現時間)。但理想狀況下，宕機一臺，只損失1/N的流量就好了。我們采用了sticky數據源解決了這個問題，使得在概率上大致只損失1/N的流量,如下圖所示:

而配合錯誤計數的話，總流量的損失會更小(因為故障窗口短)

如上圖所示，只有在故障時間內隨機選擇到中間件2(不可用)的請求才會失敗，再讓我們看下整個應用集群的情況。

只有sticky到中間件2的請求流量才有損失，由于是隨機選擇，所以這個流量的損失應用在1/N。

中間件升級發布過程中的高可用

分庫分表中間件的升級發布不可避免。例如bug fix以及新功能添加等都需要重啟中間件。而重啟的時間也會導致不可用，與物理機宕機的情況相比是其不可用的時間點是可知的，重啟的動作也是可控的，那么我們就可以利用這些信息去做到流量的平滑無損。

讓client端感知即將下線

在筆者所知的很多做法中，讓client端感知下線是引入一個第三方協調者(例如zookeeper/etcd)。而我們并不想引入第三方的組件去做這個操作，因為這又會引入zookeeper的高可用問題，而且會讓client端的配置更加復雜。平滑無損的大致思路(狀態機)如下圖所示:

讓心跳流量感知下線而正常流量保持

我們可以復用之前client端檢測不可用的邏輯，即讓心跳的新建連接失敗，而正常請求的新建連接成功。這樣，client端就會認為Server不可用，而在內部剔除調這個server。由于我們只是模擬不可用，所以已經建立的連接和正常新建的連接(非心跳)都是正?？捎玫?，如下圖所示:

心跳連接的創建在server端可以通過其第一條執行的是mysql的ping而正常流量第一條執行的是一條sql來區分(當然我們采用的Druid連接池在新建連接成功以后也會ping一下，所以采用了另一種方式區分,這個細節在這里就不闡述了)。

三次心跳失敗后，client端判定Server1失敗，需要將連接到server1的連接銷毀。其思路是，業務層用完連接返回連接池的時候,直接給close掉(當然這個是簡單的描述，實際操作到Druid數據源也是有細微的差別的)。

由于配置了一個connection最長保持時間,所以在這個時間之后肯定會對Server1的連接數為0

由于線上流量也不低,這個收斂時間是比較快的(進一步的做法，其實是主動去銷毀,不過我們尚未做這個操作)。

如何判定下線Server再也沒有流量

在上述小心翼翼的操作之后，在Server1下線的過程中，是不會有流量損失的。但是我們在Server端還需要判定何時不會再有新的流量,這個判定標準即是Server1沒有任何一個client端的連接。

這也是上面我們在執行完sql后銷毀連接從而可以讓連接數變為0的原因，如下圖所示:

當連接數為0后，我們就可以重新發布Server1(分庫分表中間件)了。對于這一點，我們寫了個腳本,其偽代碼如下所示:

while(true){ 
    count =`netstat -anp | grep port | grep ESTABLISHED | wc -l` 
    if(0 == count){ 
        // 流量已經為0，關掉服務器 
        kill Server 
        // 發布升級服務器 
        public Server 
        break 
    }else{ 
        Sleep(30s) 
    } 
} 

將這個腳本接入發布平臺，即可進行滾動式上下線了。

現在可以解釋下recover_time為何要較長了，因為新建連接也會導致腳本計算出來的 connection count數量增加，所以需要一個時間窗口不去建立心跳，從而能讓這個腳本順利運行。

recover_time其實是非必要的

如果我們將心跳創建的端口號和正常流量的端口號分開，是不需要recover_time的，如下圖所示:

圖片

采用這種方案的話，會在很大程度上降低我們client端代碼的復雜度。

但是這樣無疑又給client端增加了一個新的配置，對使用人員就又多了一個負擔，還得在網絡上多一次開墻的操作，所以我們采取了recover_time的方案。

中間件的啟動順序問題

前面的過程是一個優雅下線的過程，但我們發現我們的中間件才上線的時候在某些情況下也不會優雅。即在中間件啟動時候，如果對后端數據庫剛建立的連接建立上去后由于某些原因斷開了，會導致中間件的reactor線程卡住一分鐘左右，這段時間無法服務，造成流量損失。所以我們在后端數據庫連接全部創建成功后，再啟動reactor的accept線程從而接收新的流量，從而解決這一問題，如下圖所示:

總結

筆者個人感覺高可用比高性能還要復雜。因為高性能可以在線下反復的去壓測，通過壓測的數據去分析瓶頸，提高性能。而高可用需要應付線上各種千奇百怪的現象，本篇博客講述的高可用方案只是我們工作的一小部分，還有很大一部分精力是處理中間件本身的問題上。但只要不放過任何一個點，將問題都能夠分析清楚并解決，就會讓系統越來越好。

本文轉載自微信公眾號「解Bug之路」，可以通過以下二維碼關注。轉載本文請聯系解Bug之路公眾號。