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

隨著同程和藝龍兩家公司的合并，越來越多的系統需要打通同程 APP、藝龍 APP、同程微信小程序、藝龍微信小程序等多平臺會員體系。

例如微信小程序的交叉營銷，用戶買了一張火車票，此時想給他發酒店紅包，這就需要查詢該用戶的統一會員關系。

因為火車票用的是同程會員體系，酒店用的是藝龍會員體系，只有查到對應的藝龍會員卡號后，才能將紅包掛載到該會員賬號。

除了上述講的交叉營銷，還有許多場景需要查詢統一會員關系，例如訂單中心、會員等級、里程、紅包、常旅、實名，以及各類營銷活動等等。

所以，會員系統的請求量越來越大，并發量越來越高，今年清明小長假的秒并發 tps 甚至超過 2 萬多。

在如此大流量的沖擊下，會員系統是如何做到高性能和高可用的呢？這就是本文著重要講述的內容。

ES 高可用方案

| 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 主集群。

| ES 流量隔離三集群架構

雙中心 ES 主備集群做到這一步，感覺應該沒啥大問題了，但去年的一次恐怖流量沖擊讓我們改變了想法。

那是一個節假日，某個業務上線了一個營銷活動，在用戶的一次請求中，循環 10 多次調用了會員系統，導致會員系統的 tps 暴漲，差點把 ES 集群打爆。

這件事讓我們后怕不已，它讓我們意識到，一定要對調用方進行優先級分類，實施更精細的隔離、熔斷、降級、限流策略。

首先，我們梳理了所有調用方，分出兩大類請求類型：

第一類是跟用戶的下單主流程密切相關的請求，這類請求非常重要，應該高優先級保障。

第二類是營銷活動相關的，這類請求有個特點，他們的請求量很大，tps 很高，但不影響下單主流程。

基于此，我們又構建了一個 ES 集群，專門用來應對高 tps 的營銷秒殺類請求，這樣就跟 ES 主集群隔離開來，不會因為某個營銷活動的流量沖擊而影響用戶的下單主流程。

如下圖所示：

| 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 無法交叉營銷等等。

那后來為什么又要做緩存呢？是因為今年機票的盲盒活動，它帶來的瞬時并發太高了。雖然會員系統安然無恙，但還是有點心有余悸，穩妥起見，最終還是決定實施緩存方案。

| 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 的壓力，會員系統整體性能得到了很大提升。

| Redis 雙中心多集群架構

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

如下圖所示：

關于 Redis 集群的高可用，我們采用了雙中心多集群的模式。在機房 A 和機房 B 各部署一套 Redis 集群。

更新緩存數據時，雙寫，只有兩個機房的 Redis 集群都寫成功了，才返回成功。查詢緩存數據時，機房內就近查詢，降低延時。這樣，即使機房 A 整體故障，機房 B 還能提供完整的會員服務。

高可用會員主庫方案

上述講到，全平臺會員的綁定關系數據存在 ES，而會員的注冊明細數據存在關系型數據庫。

最早，會員使用的數據庫是 SqlServer，直到有一天，DBA 找到我們說，單臺 SqlServer 數據庫已經存儲了十多億的會員數據，服務器已達到物理極限，不能再擴展了。按照現在的增長趨勢，過不了多久，整個 SqlServer 數據庫就崩了。

你想想，那是一種什么樣的災難場景：會員數據庫崩了，會員系統就崩了；會員系統崩了，全公司所有業務線就崩了。想想就不寒而栗，酸爽無比，為此我們立刻開啟了遷移 DB 的工作。

| MySQL 雙中心 Partition 集群方案

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

會員一共有十多億的數據，我們把會員主庫分了 1000 多個分片，平分到每個分片大概百萬的量級，足夠使用了。

MySQL 集群采用 1 主 3 從的架構，主庫放在機房 A，從庫放在機房 B，兩個機房之間通過專線同步數據，延遲在 1 毫秒內。

會員系統通過 DBRoute 讀寫數據，寫數據都路由到 master 節點所在的機房 A，讀數據都路由到本地機房，就近訪問，減少網絡延遲。

這樣，采用雙中心的 MySQL 集群架構，極大提高了可用性，即使機房 A 整體都崩了，還可以將機房 B 的 Slave 升級為 Master，繼續提供服務。

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

| 會員主庫平滑遷移方案

接下來的工作，就是把會員系統的底層存儲從 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 集群。

| MySQL 和 ES 主備集群方案

做到這一步，感覺會員主庫應該沒問題了，可 dal 組件的一次嚴重故障改變了我們的想法。

那次故障很恐怖，公司很多應用連接不上數據庫了，創單量直線往下掉，這讓我們意識到，即使數據庫是好的，但 dal 組件異常，依然能讓會員系統掛掉。

所以，我們再次異構了會員主庫的數據源，雙寫數據到 ES，如下所示：

如果 dal 組件故障或 MySQL 數據庫掛了，可以把讀寫切到 ES，等 MySQL 恢復了，再把數據同步到 MySQL，最后把讀寫再切回到 MySQL 數據庫。

如下圖所示：

異常會員關系治理

會員系統不僅僅要保證系統的穩定和高可用，數據的精準和正確也同樣重要。

舉個例子，一個分布式并發故障，導致一名用戶的 APP 賬戶綁定了別人的微信小程序賬戶，這將會帶來非常惡劣的影響。

首先，一旦這兩個賬號綁定了，那么這兩個用戶下的酒店、機票、火車票訂單是互相可以看到的。

你想想，別人能看到你訂的酒店訂單，你火不火，會不會投訴？除了能看到別人的訂單，你還能操作訂單。

例如，一個用戶在 APP 的訂單中心，看到了別人訂的機票訂單，他覺得不是自己的訂單，就把訂單取消了。

這將會帶來非常嚴重的客訴，大家知道，機票退訂費用是挺高的，這不僅影響了該用戶的正常出行，還導致了比較大的經濟損失，非常糟糕。

針對這些異常會員賬號，我們進行了詳細的梳理，通過非常復雜燒腦的邏輯識別出這些賬號，并對會員接口進行了深度優化治理，在代碼邏輯層堵住了相關漏洞，完成了異常會員的治理工作。

如下圖所示：

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

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

| 更精細化的流控策略

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

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

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

| 更精細化的降級策略

基于平均響應時間的降級。會員接口也有依賴其他接口，當調用其他接口的平均響應時間超過閾值，進入準降級狀態。

如果接下來 1s 內進入的請求，它們的平均響應時間都持續超過閾值，那么在接下的時間窗口內，自動地熔斷。

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

目前，我們最大的痛點是會員調用賬號的治理。公司內，想要調用會員接口，必須申請一個調用賬號，我們會記錄該賬號的使用場景，并設置流控、降級策略的規則。

但在實際使用的過程中，申請了該賬號的同事，可能異動到其他部門了，此時他可能也會調用會員系統，為了省事，他不會再次申請會員賬號，而是直接沿用以前的賬號過來調用，這導致我們無法判斷一個會員賬號的具體使用場景是什么，也就無法實施更精細的流控和降級策略。

所以，接下來，我們將會對所有調用賬號進行一個個的梳理，這是個非常龐大且繁瑣的工作，但無路如何，硬著頭皮也要做好。

編輯：黃飛