一、背景
會員系統是一種基礎系統，跟公司所有業務線的下單主流程密切相關。如果會員系統出故障，會導緻使用者無法下單，影響範圍是全公司所有業務線。是以，會員系統必須保證高性能、高可用，提供穩定、高效的基礎服務。
随着同程和藝龍兩家公司的合并，越來越多的系統需要打通同程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分鐘内的異常數超過門檻值，或者每秒異常總數占通過量的比值超過門檻值，進入降級狀态，在接下的時間視窗之内，自動熔斷。
目前，我們最大的痛點是會員調用賬号的治理。公司内，想要調用會員接口，必須申請一個調用賬号，我們會記錄該賬号的使用場景，并設定流控、降級政策的規則。但在實際使用的過程中，申請了該賬号的同僚，可能異動到其他部門了，此時他可能也會調用會員系統，為了省事，他不會再次申請會員賬号，而是直接沿用以前的賬号過來調用，這導緻我們無法判斷一個會員賬号的具體使用場景是什麼，也就無法實施更精細的流控和降級政策。是以，接下來，我們将會對所有調用賬号進行一個個的梳理，這是個非常龐大且繁瑣的工作，但無路如何，硬着頭皮也要做好。
作者丨田志良
來源丨公衆号： 同程藝龍技術中心（ID：tcyanfa）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]
關注公衆号【dbaplus社群】，擷取更多原創技術文章和精選工具下載下傳