文章來源:【公眾號:同程藝龍技術中心】 背景 會員系統是一種基礎系統,跟公司所有業務線的下單主流程密切相關。如果會員系統出故障,會導致用戶無法下單,影響範圍是全公司所有業務線。所以,會員系統必須保證高性能、高可用,提供穩定、高效的基礎服務。 隨著同程和藝龍兩家公司的合併,越來越多的系統需要打通同程 ...
文章來源:【公眾號:同程藝龍技術中心】
背景
會員系統是一種基礎系統,跟公司所有業務線的下單主流程密切相關。如果會員系統出故障,會導致用戶無法下單,影響範圍是全公司所有業務線。所以,會員系統必須保證高性能、高可用,提供穩定、高效的基礎服務。
隨著同程和藝龍兩家公司的合併,越來越多的系統需要打通同程 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 分鐘內的異常數超過閾值,或者每秒異常總數占通過量的比值超過閾值,進入降級狀態,在接下的時間視窗之內,自動熔斷。
目前,我們最大的痛點是會員調用賬號的治理。公司內,想要調用會員介面,必須申請一個調用賬號,我們會記錄該賬號的使用場景,並設置流控、降級策略的規則。
但在實際使用的過程中,申請了該賬號的同事,可能異動到其他部門了,此時他可能也會調用會員系統,為了省事,他不會再次申請會員賬號,而是直接沿用以前的賬號過來調用,這導致我們無法判斷一個會員賬號的具體使用場景是什麼,也就無法實施更精細的流控和降級策略。
所以,接下來,我們將會對所有調用賬號進行一個個的梳理,這是個非常龐大且繁瑣的工作,但無路如何,硬著頭皮也要做好。
近期熱文推薦:
1.1,000+ 道 Java面試題及答案整理(2022最新版)
4.別再寫滿屏的爆爆爆炸類了,試試裝飾器模式,這才是優雅的方式!!
覺得不錯,別忘了隨手點贊+轉發哦!