ES+Redis+MySQL，這個高可用架構設計太頂了

一、背景會員系統是一種基礎系統，跟公司所有業務線的下單主流程密切相關。如果會員系統出故障，會導致用戶無法下單，影響範圍是全公司所有業務線。所以，會員系統必須保證高性能、高可用，提供穩定、高效的基礎服務。隨著同程和藝龍兩家公司的合併，越來越多的系統需要打通同程APP、藝龍APP、同程微信小程式、藝 ...

一、背景

會員系統是一種基礎系統，跟公司所有業務線的下單主流程密切相關。如果會員系統出故障，會導致用戶無法下單，影響範圍是全公司所有業務線。所以，會員系統必須保證高性能、高可用，提供穩定、高效的基礎服務。

隨著同程和藝龍兩家公司的合併，越來越多的系統需要打通同程APP、藝龍APP、同程微信小程式、藝龍微信小程式等多平臺會員體系。例如微信小程式的交叉營銷，用戶買了一張火車票，此時想給他發酒店紅包，這就需要查詢該用戶的統一會員關係。因為火車票用的是同程會員體系，酒店用的是藝龍會員體系，只有查到對應的藝龍會員卡號後，才能將紅包掛載到該會員賬號。除了上述講的交叉營銷，還有許多場景需要查詢統一會員關係，例如訂單中心、會員等級、里程、紅包、常旅、實名，以及各類營銷活動等等。所以，會員系統的請求量越來越大，併發量越來越高，今年五一小長假的秒併發tps甚至超過2萬多。在如此大流量的衝擊下，會員系統是如何做到高性能和高可用的呢？這就是本文著重要講述的內容。

二、ES高可用方案

1. ES雙中心主備集群架構

同程和藝龍兩家公司融合後，全平臺所有體系的會員總量是十多億。在這麼大的數據體量下，業務線的查詢維度也比較複雜。有的業務線基於手機號，有的基於微信unionid，也有的基於藝龍卡號等查詢會員信息。這麼大的數據量，又有這麼多的查詢維度，基於此，我們選擇ES用來存儲統一會員關係。ES集群在整個會員系統架構中非常重要，那麼如何保證ES的高可用呢？

首先我們知道，ES集群本身就是保證高可用的，如下圖所示：

圖片

當ES集群有一個節點宕機了，會將其他節點對應的Replica Shard升級為Primary Shard，繼續提供服務。但即使是這樣，還遠遠不夠。例如ES集群都部署在機房A，現在機房A突然斷電了，怎麼辦？例如伺服器硬體故障，ES集群大部分機器宕機了，怎麼辦？或者突然有個非常熱門的搶購秒殺活動，帶來了一波非常大的流量，直接把ES集群打死了，怎麼辦？面對這些情況，讓運維兄弟衝到機房去解決？這個非常不現實，因為會員系統直接影響全公司所有業務線的下單主流程，故障恢復的時間必須非常短，如果需要運維兄弟人工介入，那這個時間就太長了，是絕對不能容忍的。那ES的高可用如何做呢？我們的方案是ES雙中心主備集群架構。

我們有兩個機房，分別是機房A和機房B。我們把ES主集群部署在機房A，把ES備集群部署在機房B。會員系統的讀寫都在ES主集群，通過MQ將數據同步到ES備集群。此時，如果ES主集群崩了，通過統一配置，將會員系統的讀寫切到機房B的ES備集群上，這樣即使ES主集群掛了，也能在很短的時間內實現故障轉移，確保會員系統的穩定運行。最後，等ES主集群故障恢復後，打開開關，將故障期間的數據同步到ES主集群，等數據同步一致後，再將會員系統的讀寫切到ES主集群。

2. ES流量隔離三集群架構

雙中心ES主備集群做到這一步，感覺應該沒啥大問題了，但去年的一次恐怖流量衝擊讓我們改變了想法。那是一個節假日，某個業務上線了一個營銷活動，在用戶的一次請求中，迴圈10多次調用了會員系統，導致會員系統的tps暴漲，差點把ES集群打爆。這件事讓我們後怕不已，它讓我們意識到，一定要對調用方進行優先順序分類，實施更精細的隔離、熔斷、降級、限流策略。首先，我們梳理了所有調用方，分出兩大類請求類型。第一類是跟用戶的下單主流程密切相關的請求，這類請求非常重要，應該高優先順序保障。第二類是營銷活動相關的，這類請求有個特點，他們的請求量很大，tps很高，但不影響下單主流程。基於此，我們又構建了一個ES集群，專門用來應對高tps的營銷秒殺類請求，這樣就跟ES主集群隔離開來，不會因為某個營銷活動的流量衝擊而影響用戶的下單主流程。如下圖所示：

圖片

3. ES集群深度優化提升

講完了ES的雙中心主備集群高可用架構，接下來我們深入講解一下ES主集群的優化工作。有一段時間，我們特別痛苦，就是每到飯點，ES集群就開始報警，搞得每次吃飯都心慌慌的，生怕ES集群一個扛不住，就全公司炸鍋了。那為什麼一到飯點就報警呢？因為流量比較大，導致ES線程數飆高，cpu直往上竄，查詢耗時增加，並傳導給所有調用方，導致更大範圍的延時。那麼如何解決這個問題呢？通過深入ES集群，我們發現了以下幾個問題：

ES負載不合理，熱點問題嚴重。ES主集群一共有幾十個節點，有的節點上部署的shard數偏多，有的節點部署的shard數很少，導致某些伺服器的負載很高，每到流量高峰期，就經常預警。
ES線程池的大小設置得太高，導致cpu飆高。我們知道，設置ES的threadpool，一般將線程數設置為伺服器的cpu核數，即使ES的查詢壓力很大，需要增加線程數，那最好也不要超過“cpu core * 3 / 2 + 1”。如果設置的線程數過多，會導致cpu在多個線程上下文之間頻繁來回切換，浪費大量cpu資源。
shard分配的記憶體太大，100g，導致查詢變慢。我們知道，ES的索引要合理分配shard數，要控制一個shard的記憶體大小在50g以內。如果一個shard分配的記憶體過大，會導致查詢變慢，耗時增加，嚴重拖累性能。
string類型的欄位設置了雙欄位，既是text，又是keyword，導致存儲容量增大了一倍。會員信息的查詢不需要關聯度打分，直接根據keyword查詢就行，所以完全可以將text欄位去掉，這樣就能節省很大一部分存儲空間，提升性能。
ES查詢，使用filter，不使用query。因為query會對搜索結果進行相關度算分，比較耗cpu，而會員信息的查詢是不需要算分的，這部分的性能損耗完全可以避免。
節約ES算力，將ES的搜索結果排序放在會員系統的jvm記憶體中進行。
增加routing key。我們知道，一次ES查詢，會將請求分發給所有shard，等所有shard返回結果後再聚合數據，最後將結果返回給調用方。如果我們事先已經知道數據分佈在哪些shard上，那麼就可以減少大量不必要的請求，提升查詢性能。

經過以上優化，成果非常顯著，ES集群的cpu大幅下降，查詢性能大幅提升。ES集群的cpu使用率：

會員系統的介面耗時：

圖片

三、會員Redis緩存方案

一直以來，會員系統是不做緩存的，原因主要有兩個：第一個，前面講的ES集群性能很好，秒併發3萬多，99線耗時5毫秒左右，已經足夠應付各種棘手的場景。第二個，有的業務對會員的綁定關係要求實時一致，而會員是一個發展了10多年的老系統，是一個由好多介面、好多系統組成的分散式系統。所以，只要有一個介面沒有考慮到位，沒有及時去更新緩存，就會導致臟數據，進而引發一系列的問題，例如：用戶在APP上看不到微信訂單、APP和微信的會員等級、里程等沒合併、微信和APP無法交叉營銷等等。那後來為什麼又要做緩存呢？是因為今年機票的盲盒活動，它帶來的瞬時併發太高了。雖然會員系統安然無恙，但還是有點心有餘悸，穩妥起見，最終還是決定實施緩存方案。

1. ES近一秒延時導致的Redis緩存數據不一致問題的解決方案

在做會員緩存方案的過程中，遇到一個ES引發的問題，該問題會導致緩存數據的不一致。我們知道，ES操作數據是近實時的，往ES新增一個Document，此時立即去查，是查不到的，需要等待1秒後才能查詢到。如下圖所示：

ES的近實時機製為什麼會導致redis緩存數據不一致呢？具體來講，假設一個用戶註銷了自己的APP賬號，此時需要更新ES，刪除APP賬號和微信賬號的綁定關係。而ES的數據更新是近實時的，也就是說，1秒後你才能查詢到更新後的數據。而就在這1秒內，有個請求來查詢該用戶的會員綁定關係，它先到redis緩存中查，發現沒有，然後到ES查，查到了，但查到的是更新前的舊數據。最後，該請求把查詢到的舊數據更新到redis緩存並返回。就這樣，1秒後，ES中該用戶的會員數據更新了，但redis緩存的數據還是舊數據，導致了redis緩存跟ES的數據不一致。如下圖所示：

面對該問題，如何解決呢？我們的思路是，在更新ES數據時，加一個2秒的redis分散式併發鎖，為了保證緩存數據的一致性，接著再刪除redis中該會員的緩存數據。如果此時有請求來查詢數據，先獲取分散式鎖，發現該會員ID已經上鎖了，說明ES剛剛更新的數據尚未生效，那麼此時查詢完數據後就不更新redis緩存了，直接返回，這樣就避免了緩存數據的不一致問題。如下圖所示：

圖片

上述方案，乍一看似乎沒什麼問題了，但仔細分析，還是有可能導致緩存數據的不一致。例如，在更新請求加分散式鎖之前，恰好有一個查詢請求獲取分散式鎖，而此時是沒有鎖的，所以它可以繼續更新緩存。但就在他更新緩存之前，線程block了，此時更新請求來了，加了分散式鎖，並刪除了緩存。當更新請求完成操作後，查詢請求的線程活過來了，此時它再執行更新緩存，就把臟數據寫到緩存中了。發現沒有？主要的問題癥結就在於“刪除緩存”和“更新緩存”發生了併發衝突，只要將它們互斥，就能解決問題。如下圖所示：

圖片

實施了緩存方案後，經統計，緩存命中率90%+，極大緩解了ES的壓力，會員系統整體性能得到了很大提升。

2. Redis雙中心多集群架構

接下來，我們看一下如何保障Redis集群的高可用。如下圖所示：

關於Redis集群的高可用，我們採用了雙中心多集群的模式。在機房A和機房B各部署一套Redis集群。更新緩存數據時，雙寫，只有兩個機房的redis集群都寫成功了，才返回成功。查詢緩存數據時，機房內就近查詢，降低延時。這樣，即使機房A整體故障，機房B還能提供完整的會員服務。

四、高可用會員主庫方案

上述講到，全平臺會員的綁定關係數據存在ES，而會員的註冊明細數據存在關係型資料庫。最早，會員使用的資料庫是SqlServer，直到有一天，DBA找到我們說，單台SqlServer資料庫已經存儲了十多億的會員數據，伺服器已達到物理極限，不能再擴展了。按照現在的增長趨勢，過不了多久，整個SqlServer資料庫就崩了。你想想，那是一種什麼樣的災難場景：會員資料庫崩了，會員系統就崩了；會員系統崩了，全公司所有業務線就崩了。想想就不寒而慄，酸爽無比，為此我們立刻開啟了遷移DB的工作。

1. MySql雙中心Partition集群方案

經過調研，我們選擇了雙中心分庫分表的MySql集群方案，如下圖所示：

會員一共有十多億的數據，我們把會員主庫分了1000多個分片，平分到每個分片大概百萬的量級，足夠使用了。MySql集群採用1主3從的架構，主庫放在機房A，從庫放在機房B，兩個機房之間通過專線同步數據，延遲在1毫秒內。會員系統通過DBRoute讀寫數據，寫數據都路由到master節點所在的機房A，讀數據都路由到本地機房，就近訪問，減少網路延遲。這樣，採用雙中心的MySql集群架構，極大提高了可用性，即使機房A整體都崩了，還可以將機房B的Slave升級為Master，繼續提供服務。

雙中心MySql集群搭建好後，我們進行了壓測，測試下來，秒併發能達到2萬多，平均耗時在10毫秒內，性能達標。

2. 會員主庫平滑遷移方案

接下來的工作，就是把會員系統的底層存儲從SqlServer切到MySql上，這是個風險極高的工作，主要有以下幾個難點：

會員系統是一刻都不能停機的，要在不停機的情況下完成SqlServer到MySql的切換，就像是在給高速行駛的汽車換輪子。
會員系統是由很多個系統和介面組成的，畢竟發展了10多年，由於歷史原因，遺留了大量老介面，邏輯錯綜複雜。這麼多系統，必須一個不落的全部梳理清楚，DAL層代碼必須重寫，而且不能出任何問題，否則將是災難性的。
數據的遷移要做到無縫遷移，不僅是存量10多億數據的遷移，實時產生的數據也要無縫同步到mysql。另外，除了要保障數據同步的實時性，還要保證數據的正確性，以及SqlServer和MySql數據的一致性。

基於以上痛點，我們設計了“全量同步、增量同步、實時流量灰度切換”的技術方案。

首先，為了保證數據的無縫切換，採用實時雙寫的方案。因為業務邏輯的複雜，以及SqlServer和MySql的技術差異性，在雙寫mysql的過程中，不一定會寫成功，而一旦寫失敗，就會導致SqlServer和MySql的數據不一致，這是絕不允許的。所以，我們採取的策略是，在試運行期間，主寫SqlServer，然後通過線程池非同步寫MySql，如果寫失敗了，重試三次，如果依然失敗，則記日誌，然後人工排查原因，解決後，繼續雙寫，直到運行一段時間，沒有雙寫失敗的情況。通過上述策略，可以確保在絕大部分情況下，雙寫操作的正確性和穩定性，即使在試運行期間出現了SqlServer和MySql的數據不一致的情況，也可以基於SqlServer再次全量構建出MySql的數據，因為我們在設計雙寫策略時，會確保SqlServer一定能寫成功，也就是說，SqlServer中的數據是全量最完整、最正確的。如下圖所示：

講完了雙寫，接下來我們看一下“讀數據”如何灰度。整體思路是，通過A/B平臺逐步灰度流量，剛開始100%的流量讀取SqlServer資料庫，然後逐步切流量讀取MySql資料庫，先1%，如果沒有問題，再逐步放流量，最終100%的流量都走MySql資料庫。在逐步灰度流量的過程中，需要有驗證機制，只有驗證沒問題了，才能進一步放大流量。那麼這個驗證機制如何實施呢？方案是，在一次查詢請求里，通過非同步線程，比較SqlServer和 MySql的查詢結果是否一致，如果不一致，記日誌，再人工檢查不一致的原因，直到徹底解決不一致的問題後，再逐步灰度流量。如下圖所示：

圖片

所以，整體的實施流程如下：

圖片

首先，在一個夜黑風高的深夜，流量最小的時候，完成SqlServer到MySql資料庫的全量數據同步。接著，開啟雙寫，此時，如果有用戶註冊，就會實時雙寫到兩個資料庫。那麼，在全量同步和實時雙寫開啟之間，兩個資料庫還相差這段時間的數據，所以需要再次增量同步，把數據補充完整，以防數據的不一致。剩下的時間，就是各種日誌監控，看雙寫是否有問題，看數據比對是否一致等等。這段時間是耗時最長的，也是最容易發生問題的，如果有的問題比較嚴重，導致數據不一致了，就需要從頭再來，再次基於SqlServer全量構建MySql資料庫，然後重新灰度流量，直到最後，100%的流量全部灰度到MySql，此時就大功告成了，下線灰度邏輯，所有讀寫都切到MySql集群。

3. MySql和ES主備集群方案

做到這一步，感覺會員主庫應該沒問題了，可dal組件的一次嚴重故障改變了我們的想法。那次故障很恐怖，公司很多應用連接不上資料庫了，創單量直線往下掉，這讓我們意識到，即使資料庫是好的，但dal組件異常，依然能讓會員系統掛掉。所以，我們再次異構了會員主庫的數據源，雙寫數據到ES，如下所示：

如果dal組件故障或MySql資料庫掛了，可以把讀寫切到ES，等MySql恢復了，再把數據同步到MySql，最後把讀寫再切回到MySql資料庫。如下圖所示：

圖片

五、異常會員關係治理

會員系統不僅僅要保證系統的穩定和高可用，數據的精準和正確也同樣重要。舉個例子，一個分散式併發故障，導致一名用戶的APP賬戶綁定了別人的微信小程式賬戶，這將會帶來非常惡劣的影響。首先，一旦這兩個賬號綁定了，那麼這兩個用戶下的酒店、機票、火車票訂單是互相可以看到的。你想想，別人能看到你訂的酒店訂單，你火不火，會不會投訴？除了能看到別人的訂單，你還能操作訂單。例如，一個用戶在APP的訂單中心，看到了別人訂的機票訂單，他覺得不是自己的訂單，就把訂單取消了。這將會帶來非常嚴重的客訴，大家知道，機票退訂費用是挺高的，這不僅影響了該用戶的正常出行，還導致了比較大的經濟損失，非常糟糕。

針對這些異常會員賬號，我們進行了詳細的梳理，通過非常複雜燒腦的邏輯識別出這些賬號，並對會員介面進行了深度優化治理，在代碼邏輯層堵住了相關漏洞，完成了異常會員的治理工作。如下圖所示：

圖片

六、展望：更精細化的流控和降級策略

任何一個系統，都不能保證百分之一百不出問題，所以我們要有面向失敗的設計，那就是更精細化的流控和降級策略。

1. 更精細化的流控策略

熱點控制。針對黑產刷單的場景，同一個會員id會有大量重覆的請求，形成熱點賬號，當這些賬號的訪問超過設定閾值時，實施限流策略。

基於調用賬號的流控規則。這個策略主要是防止調用方的代碼bug導致的大流量。例如，調用方在一次用戶請求中，迴圈很多次來調用會員介面，導致會員系統流量暴增很多倍。所以，要針對每個調用賬號設置流控規則，當超過閾值時，實施限流策略。

全局流控規則。我們會員系統能抗下tps 3萬多的秒併發請求量，如果此時，有個很恐怖的流量打過來，tps高達10萬，與其讓這波流量把會員資料庫、es全部打死，還不如把超過會員系統承受範圍之外的流量快速失敗，至少tps 3萬內的會員請求能正常響應，不會讓整個會員系統全部崩潰。

圖片

2. 更精細化的降級策略

基於平均響應時間的降級。會員介面也有依賴其他介面，當調用其他介面的平均響應時間超過閾值，進入準降級狀態。如果接下來 1s 內進入的請求，它們的平均響應時間都持續超過閾值，那麼在接下的時間視窗內，自動地熔斷。

基於異常數和異常比例的降級。當會員介面依賴的其他介面發生異常，如果1分鐘內的異常數超過閾值，或者每秒異常總數占通過量的比值超過閾值，進入降級狀態，在接下的時間視窗之內，自動熔斷。

目前，我們最大的痛點是會員調用賬號的治理。公司內，想要調用會員介面，必須申請一個調用賬號，我們會記錄該賬號的使用場景，並設置流控、降級策略的規則。但在實際使用的過程中，申請了該賬號的同事，可能異動到其他部門了，此時他可能也會調用會員系統，為了省事，他不會再次申請會員賬號，而是直接沿用以前的賬號過來調用，這導致我們無法判斷一個會員賬號的具體使用場景是什麼，也就無法實施更精細的流控和降級策略。所以，接下來，我們將會對所有調用賬號進行一個個的梳理，這是個非常龐大且繁瑣的工作，但無路如何，硬著頭皮也要做好。

作者|我的尤克裡里

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/ES_Redis_MySQL-this-highly-available-architecture-design-is-too-top-notch.html