背景 會員系統(tǒng)是一種基礎系統(tǒng)，跟公司所有業(yè)務線的下單主流程密切相關。如果會員系統(tǒng)出故障，會導致用戶無法下單，影響范圍是全公司所有業(yè)務線。所以，會員系統(tǒng)必須保證高性能、高可用，提供穩(wěn)定、高效的基礎服務。 隨著同程和藝龍兩家公司的合并，越來越多的系統(tǒng)需要打通同程 App、藝龍 APP、同程微信小程序、藝龍微信小程序等多平臺會員體系。 例如微信小程序的交叉營銷，用戶買了一張火車票，此時想給他發(fā)酒店紅包，這就需要查詢該用戶的統(tǒng)一會員關系。 因為火車票用的是同程會員體系，酒店用的是藝龍會員體系，只有查到對應的藝龍會員卡號后，才能將紅包掛載到該會員賬號。 除了上述講的交叉營銷，還有許多場景需要查詢統(tǒng)一會員關系，例如訂單中心、會員等級、里程、紅包、常旅、實名，以及各類營銷活動等等。 所以，會員系統(tǒng)的請求量越來越大，并發(fā)量越來越高，今年清明小長假的秒并發(fā) tps 甚至超過 2 萬多。 在如此大流量的沖擊下，會員系統(tǒng)是如何做到高性能和高可用的呢？這就是本文著重要講述的內(nèi)容。 ES 高可用方案 同程和藝龍兩家公司融合后，全平臺所有體系的會員總量是十多億。在這么大的數(shù)據(jù)體量下，業(yè)務線的查詢維度也比較復雜。 有的業(yè)務線基于手機號，有的基于微信 unionid，也有的基于藝龍卡號等查詢會員信息。 這么大的數(shù)據(jù)量，又有這么多的查詢維度，基于此，我們選擇 ES 用來存儲統(tǒng)一會員關系。ES 集群在整個會員系統(tǒng)架構中非常重要，那么如何保證 ES 的高可用呢？ 當 ES 集群有一個節(jié)點宕機了，會將其他節(jié)點對應的 Replica Shard 升級為 Primary Shard，繼續(xù)提供服務。 但即使是這樣，還遠遠不夠。例如 ES 集群都部署在機房 A，現(xiàn)在機房 A 突然斷電了，怎么辦？ 例如服務器硬件故障，ES 集群大部分機器宕機了，怎么辦？或者突然有個非常熱門的搶購秒殺活動，帶來了一波非常大的流量，直接把 ES 集群打死了，怎么辦？面對這些情況，讓運維兄弟沖到機房去解決？ 這個非常不現(xiàn)實，因為會員系統(tǒng)直接影響全公司所有業(yè)務線的下單主流程，故障恢復的時間必須非常短，如果需要運維兄弟人工介入，那這個時間就太長了，是絕對不能容忍的。 我們有兩個機房，分別是機房 A 和機房 B。我們把 ES 主集群部署在機房 A，把 ES 備集群部署在機房 B。會員系統(tǒng)的讀寫都在 ES 主集群，通過 MQ 將數(shù)據(jù)同步到 ES 備集群。 此時，如果 ES 主集群崩了，通過統(tǒng)一配置，將會員系統(tǒng)的讀寫切到機房 B 的 ES 備集群上，這樣即使 ES 主集群掛了，也能在很短的時間內(nèi)實現(xiàn)故障轉(zhuǎn)移，確保會員系統(tǒng)的穩(wěn)定運行。 最后，等 ES 主集群故障恢復后，打開開關，將故障期間的數(shù)據(jù)同步到 ES 主集群，等數(shù)據(jù)同步一致后，再將會員系統(tǒng)的讀寫切到 ES 主集群。 雙中心 ES 主備集群做到這一步，感覺應該沒啥大問題了，但去年的一次恐怖流量沖擊讓我們改變了想法。 那是一個節(jié)假日，某個業(yè)務上線了一個營銷活動，在用戶的一次請求中，循環(huán) 10 多次調(diào)用了會員系統(tǒng)，導致會員系統(tǒng)的 tps 暴漲，差點把 ES 集群打爆。 這件事讓我們后怕不已，它讓我們意識到，一定要對調(diào)用方進行優(yōu)先級分類，實施更精細的隔離、熔斷、降級、限流策略。 首先，我們梳理了所有調(diào)用方，分出兩大類請求類型： 第一類是跟用戶的下單主流程密切相關的請求，這類請求非常重要，應該高優(yōu)先級保障。 第二類是營銷活動相關的，這類請求有個特點，他們的請求量很大，tps 很高，但不影響下單主流程。 基于此，我們又構建了一個 ES 集群，專門用來應對高 tps 的營銷秒殺類請求，這樣就跟 ES 主集群隔離開來，不會因為某個營銷活動的流量沖擊而影響用戶的下單主流程。 講完了 ES 的雙中心主備集群高可用架構，接下來我們深入講解一下 ES 主集群的優(yōu)化工作。 有一段時間，我們特別痛苦，就是每到飯點，ES 集群就開始報警，搞得每次吃飯都心慌慌的，生怕 ES 集群一個扛不住，就全公司炸鍋了。 那為什么一到飯點就報警呢？因為流量比較大， 導致 ES 線程數(shù)飆高，cpu 直往上竄，查詢耗時增加，并傳導給所有調(diào)用方，導致更大范圍的延時。那么如何解決這個問題呢？ 通過深入 ES 集群，我們發(fā)現(xiàn)了以下幾個問題： ES 負載不合理，熱點問題嚴重。ES 主集群一共有幾十個節(jié)點，有的節(jié)點上部署的 shard 數(shù)偏多，有的節(jié)點部署的 shard 數(shù)很少，導致某些服務器的負載很高，每到流量高峰期，就經(jīng)常預警。 ES 線程池的大小設置得太高，導致 cpu 飆高。我們知道，設置 ES 的 threadpool，一般將線程數(shù)設置為服務器的 cpu 核數(shù)，即使 ES 的查詢壓力很大，需要增加線程數(shù)，那最好也不要超過“cpu core * 3 / 2 + 1”。如果設置的線程數(shù)過多，會導致 cpu 在多個線程上下文之間頻繁來回切換，浪費大量 cpu 資源。 shard 分配的內(nèi)存太大，100g，導致查詢變慢。我們知道，ES 的索引要合理分配 shard 數(shù)，要控制一個 shard 的內(nèi)存大小在 50g 以內(nèi)。如果一個 shard 分配的內(nèi)存過大，會導致查詢變慢，耗時增加，嚴重拖累性能。 string 類型的字段設置了雙字段，既是 text，又是 keyword，導致存儲容量增大了一倍。會員信息的查詢不需要關聯(lián)度打分，直接根據(jù) keyword 查詢就行，所以完全可以將 text 字段去掉，這樣就能節(jié)省很大一部分存儲空間，提升性能。 ES 查詢，使用 filter，不使用 query。因為 query 會對搜索結果進行相關度算分，比較耗 cpu，而會員信息的查詢是不需要算分的，這部分的性能損耗完全可以避免。 節(jié)約 ES 算力，將 ES 的搜索結果排序放在會員系統(tǒng)的 jvm 內(nèi)存中進行。 增加 routing key。我們知道，一次 ES 查詢，會將請求分發(fā)給所有 shard，等所有shard返回結果后再聚合數(shù)據(jù)，最后將結果返回給調(diào)用方。如果我們事先已經(jīng)知道數(shù)據(jù)分布在哪些 shard 上，那么就可以減少大量不必要的請求，提升查詢性能。 經(jīng)過以上優(yōu)化，成果非常顯著，ES 集群的 cpu 大幅下降，查詢性能大幅提升。ES 集群的 cpu 使用率： 會員 redis 緩存方案 一直以來，會員系統(tǒng)是不做緩存的，原因主要有兩個： 第一個，前面講的 ES 集群性能很好，秒并發(fā) 3 萬多，99 線耗時 5 毫秒左右，已經(jīng)足夠應付各種棘手的場景。 第二個，有的業(yè)務對會員的綁定關系要求實時一致，而會員是一個發(fā)展了 10 多年的老系統(tǒng)，是一個由好多接口、好多系統(tǒng)組成的分布式系統(tǒng)。 所以，只要有一個接口沒有考慮到位，沒有及時去更新緩存，就會導致臟數(shù)據(jù)，進而引發(fā)一系列的問題。 例如：用戶在 APP 上看不到微信訂單、APP 和微信的會員等級、里程等沒合并、微信和 APP 無法交叉營銷等等。 那后來為什么又要做緩存呢？是因為今年機票的盲盒活動，它帶來的瞬時并發(fā)太高了。雖然會員系統(tǒng)安然無恙，但還是有點心有余悸，穩(wěn)妥起見，最終還是決定實施緩存方案。 在做會員緩存方案的過程中，遇到一個 ES 引發(fā)的問題，該問題會導致緩存數(shù)據(jù)的不一致。 我們知道，ES 操作數(shù)據(jù)是近實時的，往 ES 新增一個 Document，此時立即去查，是查不到的，需要等待 1 秒后才能查詢到。 ES 的近實時機制為什么會導致 Redis 緩存數(shù)據(jù)不一致呢？具體來講，假設一個用戶注銷了自己的 APP 賬號，此時需要更新 ES，刪除 APP 賬號和微信賬號的綁定關系。而 ES 的數(shù)據(jù)更新是近實時的，也就是說，1 秒后你才能查詢到更新后的數(shù)據(jù)。 而就在這 1 秒內(nèi)，有個請求來查詢該用戶的會員綁定關系，它先到 Redis 緩存中查，發(fā)現(xiàn)沒有，然后到 ES 查，查到了，但查到的是更新前的舊數(shù)據(jù)。 最后，該請求把查詢到的舊數(shù)據(jù)更新到 Redis 緩存并返回。就這樣，1 秒后，ES 中該用戶的會員數(shù)據(jù)更新了，但 Redis 緩存的數(shù)據(jù)還是舊數(shù)據(jù)，導致了 Redis 緩存跟 ES 的數(shù)據(jù)不一致。 面對該問題，如何解決呢？我們的思路是，在更新 ES 數(shù)據(jù)時，加一個 2 秒的 Redis 分布式并發(fā)鎖，為了保證緩存數(shù)據(jù)的一致性，接著再刪除 Redis 中該會員的緩存數(shù)據(jù)。 如果此時有請求來查詢數(shù)據(jù)，先獲取分布式鎖，發(fā)現(xiàn)該會員 ID 已經(jīng)上鎖了，說明 ES 剛剛更新的數(shù)據(jù)尚未生效，那么此時查詢完數(shù)據(jù)后就不更新 Redis 緩存了，直接返回，這樣就避免了緩存數(shù)據(jù)的不一致問題。 上述方案，乍一看似乎沒什么問題了，但仔細分析，還是有可能導致緩存數(shù)據(jù)的不一致。 例如，在更新請求加分布式鎖之前，恰好有一個查詢請求獲取分布式鎖，而此時是沒有鎖的，所以它可以繼續(xù)更新緩存。 但就在他更新緩存之前，線程 block 了，此時更新請求來了，加了分布式鎖，并刪除了緩存。當更新請求完成操作后，查詢請求的線程活過來了，此時它再執(zhí)行更新緩存，就把臟數(shù)據(jù)寫到緩存中了。 發(fā)現(xiàn)沒有？主要的問題癥結就在于“刪除緩存”和“更新緩存”發(fā)生了并發(fā)沖突，只要將它們互斥，就能解決問題。 實施了緩存方案后，經(jīng)統(tǒng)計，緩存命中率 90%+，極大緩解了 ES 的壓力，會員系統(tǒng)整體性能得到了很大提升。 接下來，我們看一下如何保障 Redis 集群的高可用。 關于 Redis 集群的高可用，我們采用了雙中心多集群的模式。在機房 A 和機房 B 各部署一套 Redis 集群。 更新緩存數(shù)據(jù)時，雙寫，只有兩個機房的 Redis 集群都寫成功了，才返回成功。查詢緩存數(shù)據(jù)時，機房內(nèi)就近查詢，降低延時。這樣，即使機房 A 整體故障，機房 B 還能提供完整的會員服務。 高可用會員主庫方案 上述講到，全平臺會員的綁定關系數(shù)據(jù)存在 ES，而會員的注冊明細數(shù)據(jù)存在關系型數(shù)據(jù)庫。 最早，會員使用的數(shù)據(jù)庫是 SqlServer，直到有一天，DBA 找到我們說，單臺 SqlServer 數(shù)據(jù)庫已經(jīng)存儲了十多億的會員數(shù)據(jù)，服務器已達到物理極限，不能再擴展了。按照現(xiàn)在的增長趨勢，過不了多久，整個 SqlServer 數(shù)據(jù)庫就崩了。 你想想，那是一種什么樣的災難場景：會員數(shù)據(jù)庫崩了，會員系統(tǒng)就崩了；會員系統(tǒng)崩了，全公司所有業(yè)務線就崩了。想想就不寒而栗，酸爽無比，為此我們立刻開啟了遷移 DB 的工作。 會員一共有十多億的數(shù)據(jù)，我們把會員主庫分了 1000 多個分片，平分到每個分片大概百萬的量級，足夠使用了。 MySQL 集群采用 1 主 3 從的架構，主庫放在機房 A，從庫放在機房 B，兩個機房之間通過專線同步數(shù)據(jù)，延遲在 1 毫秒內(nèi)。 會員系統(tǒng)通過 DBRoute 讀寫數(shù)據(jù)，寫數(shù)據(jù)都路由到 master 節(jié)點所在的機房 A，讀數(shù)據(jù)都路由到本地機房，就近訪問，減少網(wǎng)絡延遲。 這樣，采用雙中心的 MySQL 集群架構，極大提高了可用性，即使機房 A 整體都崩了，還可以將機房 B 的 Slave 升級為 Master，繼續(xù)提供服務。 雙中心 MySQL 集群搭建好后，我們進行了壓測，測試下來，秒并發(fā)能達到 2 萬多，平均耗時在 10 毫秒內(nèi)，性能達標。 接下來的工作，就是把會員系統(tǒng)的底層存儲從 SqlServer 切到 MySQL 上，這是個風險極高的工作。 主要有以下幾個難點： 會員系統(tǒng)是一刻都不能停機的，要在不停機的情況下完成 SqlServer 到 MySQL 的切換，就像是在給高速行駛的汽車換輪子。 會員系統(tǒng)是由很多個系統(tǒng)和接口組成的，畢竟發(fā)展了 10 多年，由于歷史原因，遺留了大量老接口，邏輯錯綜復雜。這么多系統(tǒng)，必須一個不落的全部梳理清楚，DAL 層代碼必須重寫，而且不能出任何問題，否則將是災難性的。 數(shù)據(jù)的遷移要做到無縫遷移，不僅是存量 10 多億數(shù)據(jù)的遷移，實時產(chǎn)生的數(shù)據(jù)也要無縫同步到 MySQL。另外，除了要保障數(shù)據(jù)同步的實時性，還要保證數(shù)據(jù)的正確性，以及 SqlServer 和 MySQL 數(shù)據(jù)的一致性。 基于以上痛點，我們設計了“全量同步、增量同步、實時流量灰度切換”的技術方案。 首先，為了保證數(shù)據(jù)的無縫切換，采用實時雙寫的方案。因為業(yè)務邏輯的復雜，以及 SqlServer 和 MySQL 的技術差異性，在雙寫 MySQL 的過程中，不一定會寫成功，而一旦寫失敗，就會導致 SqlServer 和 MySQL 的數(shù)據(jù)不一致，這是絕不允許的。 所以，我們采取的策略是，在試運行期間，主寫 SqlServer，然后通過線程池異步寫 MySQL，如果寫失敗了，重試三次，如果依然失敗，則記日志，然后人工排查原因，解決后，繼續(xù)雙寫，直到運行一段時間，沒有雙寫失敗的情況。 通過上述策略，可以確保在絕大部分情況下，雙寫操作的正確性和穩(wěn)定性，即使在試運行期間出現(xiàn)了 SqlServer 和 MySQL 的數(shù)據(jù)不一致的情況，也可以基于 SqlServer 再次全量構建出 MySQL 的數(shù)據(jù)。 因為我們在設計雙寫策略時，會確保 SqlServer 一定能寫成功，也就是說，SqlServer 中的數(shù)據(jù)是全量最完整、最正確的。 講完了雙寫，接下來我們看一下“讀數(shù)據(jù)”如何灰度。整體思路是，通過 A/B 平臺逐步灰度流量，剛開始 100% 的流量讀取 SqlServer 數(shù)據(jù)庫，然后逐步切流量讀取 MySQL 數(shù)據(jù)庫，先 1%，如果沒有問題，再逐步放流量，最終 100% 的流量都走 MySQL數(shù)據(jù)庫。 在逐步灰度流量的過程中，需要有驗證機制，只有驗證沒問題了，才能進一步放大流量。 那么這個驗證機制如何實施呢？方案是，在一次查詢請求里，通過異步線程，比較 SqlServer 和 MySQL 的查詢結果是否一致，如果不一致，記日志，再人工檢查不一致的原因，直到徹底解決不一致的問題后，再逐步灰度流量。 首先，在一個夜黑風高的深夜，流量最小的時候，完成 SqlServer 到 MySQL 數(shù)據(jù)庫的全量數(shù)據(jù)同步。 接著，開啟雙寫，此時，如果有用戶注冊，就會實時雙寫到兩個數(shù)據(jù)庫。那么，在全量同步和實時雙寫開啟之間，兩個數(shù)據(jù)庫還相差這段時間的數(shù)據(jù)，所以需要再次增量同步，把數(shù)據(jù)補充完整，以防數(shù)據(jù)的不一致。 剩下的時間，就是各種日志監(jiān)控，看雙寫是否有問題，看數(shù)據(jù)比對是否一致等等。 這段時間是耗時最長的，也是最容易發(fā)生問題的，如果有的問題比較嚴重，導致數(shù)據(jù)不一致了，就需要從頭再來，再次基于 SqlServer 全量構建 MySQL 數(shù)據(jù)庫，然后重新灰度流量。 直到最后，100% 的流量全部灰度到 MySQL，此時就大功告成了，下線灰度邏輯，所有讀寫都切到 MySQL 集群。 做到這一步，感覺會員主庫應該沒問題了，可 dal 組件的一次嚴重故障改變了我們的想法。 那次故障很恐怖，公司很多應用連接不上數(shù)據(jù)庫了，創(chuàng)單量直線往下掉，這讓我們意識到，即使數(shù)據(jù)庫是好的，但 dal 組件異常，依然能讓會員系統(tǒng)掛掉。 如果 dal 組件故障或 MySQL 數(shù)據(jù)庫掛了，可以把讀寫切到 ES，等 MySQL 恢復了，再把數(shù)據(jù)同步到 MySQL，最后把讀寫再切回到 MySQL 數(shù)據(jù)庫。 | ES 雙中心主備集群架構
| ES 流量隔離三集群架構
| ES 集群深度優(yōu)化提升
| ES 近一秒延時導致的 Redis 緩存數(shù)據(jù)不一致問題的解決方案
| Redis 雙中心多集群架構
| MySQL 雙中心 Partition 集群方案
| 會員主庫平滑遷移方案
| MySQL 和 ES 主備集群方案
異常會員關系治理
會員系統(tǒng)不僅僅要保證系統(tǒng)的穩(wěn)定和高可用，數(shù)據(jù)的精準和正確也同樣重要。
舉個例子，一個分布式并發(fā)故障，導致一名用戶的 APP 賬戶綁定了別人的微信小程序賬戶，這將會帶來非常惡劣的影響。
首先，一旦這兩個賬號綁定了，那么這兩個用戶下的酒店、機票、火車票訂單是互相可以看到的。
你想想，別人能看到你訂的酒店訂單，你火不火，會不會投訴？除了能看到別人的訂單，你還能操作訂單。
例如，一個用戶在 APP 的訂單中心，看到了別人訂的機票訂單，他覺得不是自己的訂單，就把訂單取消了。
這將會帶來非常嚴重的客訴，大家知道，機票退訂費用是挺高的，這不僅影響了該用戶的正常出行，還導致了比較大的經(jīng)濟損失，非常糟糕。
針對這些異常會員賬號，我們進行了詳細的梳理，通過非常復雜燒腦的邏輯識別出這些賬號，并對會員接口進行了深度優(yōu)化治理，在代碼邏輯層堵住了相關漏洞，完成了異常會員的治理工作。
展望：更精細化的流控和降級策略
任何一個系統(tǒng)，都不能保證百分之一百不出問題，所以我們要有面向失敗的設計，那就是更精細化的流控和降級策略。
| 更精細化的流控策略
熱點控制。針對黑產(chǎn)刷單的場景，同一個會員 id 會有大量重復的請求，形成熱點賬號，當這些賬號的訪問超過設定閾值時，實施限流策略。
基于調(diào)用賬號的流控規(guī)則。這個策略主要是防止調(diào)用方的代碼 bug 導致的大流量。例如，調(diào)用方在一次用戶請求中，循環(huán)很多次來調(diào)用會員接口，導致會員系統(tǒng)流量暴增很多倍。所以，要針對每個調(diào)用賬號設置流控規(guī)則，當超過閾值時，實施限流策略。
| 更精細化的降級策略
基于平均響應時間的降級。會員接口也有依賴其他接口，當調(diào)用其他接口的平均響應時間超過閾值，進入準降級狀態(tài)。
如果接下來 1s 內(nèi)進入的請求，它們的平均響應時間都持續(xù)超過閾值，那么在接下的時間窗口內(nèi)，自動地熔斷。
基于異常數(shù)和異常比例的降級。當會員接口依賴的其他接口發(fā)生異常，如果 1 分鐘內(nèi)的異常數(shù)超過閾值，或者每秒異常總數(shù)占通過量的比值超過閾值，進入降級狀態(tài)，在接下的時間窗口之內(nèi)，自動熔斷。
目前，我們最大的痛點是會員調(diào)用賬號的治理。公司內(nèi)，想要調(diào)用會員接口，必須申請一個調(diào)用賬號，我們會記錄該賬號的使用場景，并設置流控、降級策略的規(guī)則。
但在實際使用的過程中，申請了該賬號的同事，可能異動到其他部門了，此時他可能也會調(diào)用會員系統(tǒng)，為了省事，他不會再次申請會員賬號，而是直接沿用以前的賬號過來調(diào)用，這導致我們無法判斷一個會員賬號的具體使用場景是什么，也就無法實施更精細的流控和降級策略。
所以，接下來，我們將會對所有調(diào)用賬號進行一個個的梳理，這是個非常龐大且繁瑣的工作，但無路如何，硬著頭皮也要做好。
文章來源：【公眾號：同程藝龍技術中心】
