背景

會(huì)員系統(tǒng)是一種基礎(chǔ)系統(tǒng)，跟公司所有業(yè)務(wù)線(xiàn)的下單主流程密切相關(guān)。如果會(huì)員系統(tǒng)出故障，會(huì)導(dǎo)致用戶(hù)無(wú)法下單，影響范圍是全公司所有業(yè)務(wù)線(xiàn)。所以，會(huì)員系統(tǒng)必須保證高性能、高可用，提供穩(wěn)定、高效的基礎(chǔ)服務(wù)。

隨著同程和藝龍兩家公司的合并，越來(lái)越多的系統(tǒng)需要打通同程 APP、藝龍 APP、同程微信小程序、藝龍微信小程序等多平臺(tái)會(huì)員體系。

例如微信小程序的交叉營(yíng)銷(xiāo)，用戶(hù)買(mǎi)了一張火車(chē)票，此時(shí)想給他發(fā)酒店紅包，這就需要查詢(xún)?cè)撚脩?hù)的統(tǒng)一會(huì)員關(guān)系。

因?yàn)榛疖?chē)票用的是同程會(huì)員體系，酒店用的是藝龍會(huì)員體系，只有查到對(duì)應(yīng)的藝龍會(huì)員卡號(hào)后，才能將紅包掛載到該會(huì)員賬號(hào)。

除了上述講的交叉營(yíng)銷(xiāo)，還有許多場(chǎng)景需要查詢(xún)統(tǒng)一會(huì)員關(guān)系，例如訂單中心、會(huì)員等級(jí)、里程、紅包、常旅、實(shí)名，以及各類(lèi)營(yíng)銷(xiāo)活動(dòng)等等。

所以，會(huì)員系統(tǒng)的請(qǐng)求量越來(lái)越大，并發(fā)量越來(lái)越高，今年清明小長(zhǎng)假的秒并發(fā) tps 甚至超過(guò) 2 萬(wàn)多。

在如此大流量的沖擊下，會(huì)員系統(tǒng)是如何做到高性能和高可用的呢？這就是本文著重要講述的內(nèi)容。

ES 高可用方案

| ES 雙中心主備集群架構(gòu)

同程和藝龍兩家公司融合后，全平臺(tái)所有體系的會(huì)員總量是十多億。在這么大的數(shù)據(jù)體量下，業(yè)務(wù)線(xiàn)的查詢(xún)維度也比較復(fù)雜。

有的業(yè)務(wù)線(xiàn)基于手機(jī)號(hào)，有的基于微信 unionid，也有的基于藝龍卡號(hào)等查詢(xún)會(huì)員信息。

這么大的數(shù)據(jù)量，又有這么多的查詢(xún)維度，基于此，我們選擇 ES 用來(lái)存儲(chǔ)統(tǒng)一會(huì)員關(guān)系。ES 集群在整個(gè)會(huì)員系統(tǒng)架構(gòu)中非常重要，那么如何保證 ES 的高可用呢？

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

當(dāng) ES 集群有一個(gè)節(jié)點(diǎn)宕機(jī)了，會(huì)將其他節(jié)點(diǎn)對(duì)應(yīng)的 Replica Shard 升級(jí)為 Primary Shard，繼續(xù)提供服務(wù)。

但即使是這樣，還遠(yuǎn)遠(yuǎn)不夠。例如 ES 集群都部署在機(jī)房 A，現(xiàn)在機(jī)房 A 突然斷電了，怎么辦？

例如服務(wù)器硬件故障，ES 集群大部分機(jī)器宕機(jī)了，怎么辦？或者突然有個(gè)非常熱門(mén)的搶購(gòu)秒殺活動(dòng)，帶來(lái)了一波非常大的流量，直接把 ES 集群打死了，怎么辦？ 面對(duì)這些情況，讓運(yùn)維兄弟沖到機(jī)房去解決？

這個(gè)非常不現(xiàn)實(shí)，因?yàn)闀?huì)員系統(tǒng)直接影響全公司所有業(yè)務(wù)線(xiàn)的下單主流程，故障恢復(fù)的時(shí) 間必須非常短，如果需要運(yùn)維兄弟人工介入，那這個(gè)時(shí)間就太長(zhǎng)了，是絕對(duì)不能容忍的。

那 ES 的高可用如何做呢？ 我們的方案是 ES 雙中心主備集群架構(gòu)。

我們有兩個(gè)機(jī)房，分別是機(jī)房 A 和機(jī)房 B。我們把 ES 主集群部署在機(jī)房 A，把 ES 備集群部署在機(jī)房 B。 會(huì) 員系統(tǒng)的讀寫(xiě) 都在? ES 主集群，通過(guò)? MQ 將數(shù)據(jù)同步到? ES? 備 集群。

此時(shí)，如果 ES 主集群崩了，通過(guò)統(tǒng)一配置，將會(huì)員系統(tǒng)的讀寫(xiě)切到機(jī)房 B 的 ES 備集群上，這樣即使 ES 主集群掛了，也能在很短的時(shí)間內(nèi)實(shí)現(xiàn)故障轉(zhuǎn)移，確保會(huì)員系統(tǒng)的穩(wěn)定運(yùn)行。

最后，等 ES 主集群故障恢復(fù)后，打開(kāi)開(kāi)關(guān)，將故障期間的數(shù)據(jù)同步到 ES 主集群，等數(shù)據(jù)同步一致后，再將會(huì)員系統(tǒng)的讀寫(xiě)切到 ES 主集群。

| ES 流量隔離三集群架構(gòu)

雙中心 ES 主備集群做到這一步，感覺(jué)應(yīng)該沒(méi)啥大問(wèn)題了，但去年的一次恐怖流量沖擊讓我們改變了想法。

那是一個(gè)節(jié)假日，某個(gè)業(yè)務(wù)上線(xiàn)了一個(gè)營(yíng)銷(xiāo)活動(dòng)，在用戶(hù)的一次請(qǐng)求中，循環(huán) 10 多次調(diào)用了會(huì)員系統(tǒng)，導(dǎo)致會(huì)員系統(tǒng)的 tps 暴漲，差點(diǎn)把 ES 集群打爆。

這件事讓我們后怕不已，它讓我們意識(shí)到，一定要對(duì)調(diào)用方進(jìn)行優(yōu)先級(jí)分類(lèi)，實(shí)施更精細(xì)的隔離、熔斷、降級(jí)、限流策略。

首先，我們梳理了所有調(diào)用方，分出兩大類(lèi)請(qǐng)求類(lèi)型：

• 第一類(lèi)是跟用戶(hù)的下單主流程密切相關(guān)的請(qǐng)求，這類(lèi)請(qǐng)求非常重要，應(yīng)該高優(yōu)先級(jí)保障。

• 第二類(lèi)是營(yíng)銷(xiāo)活動(dòng)相關(guān)的，這類(lèi)請(qǐng)求有個(gè)特點(diǎn)，他們的請(qǐng)求量很大，tps 很高，但不影響下單主流程。

基于此，我們又構(gòu)建了一個(gè) ES 集群，專(zhuān)門(mén)用來(lái)應(yīng)對(duì)高 tps 的營(yíng)銷(xiāo)秒殺類(lèi)請(qǐng)求，這樣就跟 ES 主集群隔離開(kāi)來(lái)，不會(huì)因?yàn)槟硞€(gè)營(yíng)銷(xiāo)活動(dòng)的流量沖擊而影響用戶(hù)的下單主流程。

如下圖所示：

| ES 集群深度優(yōu)化提升

講完了 ES 的雙中心主備集群高可用架構(gòu)，接下來(lái)我們深入講解一下 ES 主集群的優(yōu)化工作。

有一段時(shí)間，我們特別痛苦，就是每到飯點(diǎn)，ES 集群就開(kāi)始報(bào)警，搞得每次吃飯都心慌慌的，生怕 ES 集群一個(gè)扛不住，就全公司炸鍋了。

那為什么一到飯點(diǎn)就報(bào)警呢？因?yàn)榱髁勘容^大， 導(dǎo)致 ES 線(xiàn)程數(shù)飆高，cpu 直往上竄，查詢(xún)耗時(shí)增加，并傳導(dǎo)給所有調(diào)用方，導(dǎo)致更大范圍的延時(shí)。那么如何解決這個(gè)問(wèn)題呢？

通過(guò)深入 ES 集群，我們發(fā)現(xiàn)了以下幾個(gè)問(wèn)題：?

• ES 負(fù)載不合理，熱點(diǎn)問(wèn)題嚴(yán)重。 ES 主集群一共有幾十個(gè)節(jié)點(diǎn)，有的節(jié)點(diǎn)上部署的 shard 數(shù)偏多，有的節(jié)點(diǎn)部署的 shard 數(shù)很少，導(dǎo)致某些服務(wù)器的負(fù)載很高，每到流量高峰期，就經(jīng)常預(yù)警。

• ES 線(xiàn)程池的大小設(shè)置得太高，導(dǎo)致 cpu 飆高。 我們知道，設(shè)置 ES 的 threadpool，一般將線(xiàn)程數(shù)設(shè)置為服務(wù)器的 cpu 核數(shù)，即使 ES 的查詢(xún)壓力很大，需要增加線(xiàn)程數(shù)，那最好也不要超過(guò)“cpu core * 3 / 2 + 1”。如果設(shè)置的線(xiàn)程數(shù)過(guò)多，會(huì)導(dǎo)致 cpu 在多個(gè)線(xiàn)程上下文之間頻繁來(lái)回切換，浪費(fèi)大量 cpu 資源。

• shard 分配的內(nèi)存太大，100g，導(dǎo)致查詢(xún)變慢。 我們知道，ES 的索引要合理分配 shard 數(shù)，要控制一個(gè) shard 的內(nèi)存大小在 50g 以?xún)?nèi)。如果一個(gè) shard 分配的內(nèi)存過(guò)大，會(huì)導(dǎo)致查詢(xún)變慢，耗時(shí)增加，嚴(yán)重拖累性能。

• string 類(lèi)型的字段設(shè)置了雙字段，既是 text，又是 keyword，導(dǎo)致存儲(chǔ)容量增大了一倍。 會(huì)員信息的查詢(xún)不需要關(guān)聯(lián)度打分，直接根據(jù) keyword 查詢(xún)就行，所以完全可以將 text 字段去掉，這樣就能節(jié)省很大一部分存儲(chǔ)空間，提升性能。

• ES 查詢(xún)，使用 filter，不使用 query。 因?yàn)?query 會(huì)對(duì)搜索結(jié)果進(jìn)行相關(guān)度算分，比較耗 cpu，而會(huì)員信息的查詢(xún)是不需要算分的，這部分的性能損耗完全可以避免。

• 節(jié)約 ES 算力， 將 ES 的搜索結(jié)果排序放在會(huì)員系統(tǒng)的 jvm 內(nèi)存中進(jìn)行。

• 增加 routing key。 我們知道，一次 ES 查詢(xún)，會(huì)將請(qǐng)求分發(fā)給所有 shard，等所有shard返回結(jié)果后再聚合數(shù)據(jù)，最后將結(jié)果返回給調(diào)用方。如果我們事先已經(jīng)知道數(shù)據(jù)分布在哪些 shard 上，那么就可以減少大量不必要的請(qǐng)求，提升查詢(xún)性能。

經(jīng)過(guò)以上優(yōu)化，成果非常顯著，ES 集群的 cpu 大幅下降，查詢(xún)性能大幅提升。ES 集群的 cpu 使用率：?

會(huì)員系統(tǒng)的接口耗時(shí)：

會(huì)員 Redis 緩存方案

一直以來(lái)，會(huì)員系統(tǒng)是不做緩存的，原因主要有兩個(gè)：

• 第一個(gè)，前面講的 ES 集群性能很好，秒并發(fā) 3 萬(wàn)多，99 線(xiàn)耗時(shí) 5 毫秒左右，已經(jīng)足夠應(yīng)付各種棘手的場(chǎng)景。

• 第二個(gè)，有的業(yè)務(wù)對(duì)會(huì)員的綁定關(guān)系要求實(shí)時(shí)一致，而會(huì)員是一個(gè)發(fā)展了 10 多年的老系統(tǒng)，是一個(gè)由好多接口、好多系統(tǒng)組成的分布式系統(tǒng)。

所以，只要有一個(gè)接口沒(méi)有考慮到位，沒(méi)有及時(shí)去更新緩存，就會(huì)導(dǎo)致臟數(shù)據(jù)，進(jìn)而引發(fā)一系列的問(wèn)題。

例如：用戶(hù)在 APP 上看不到微信訂單、APP 和微信的會(huì)員等級(jí)、里程等沒(méi)合并、微信和 APP 無(wú)法交叉營(yíng)銷(xiāo)等等。

那后來(lái)為什么又要做緩存呢？是因?yàn)榻衲隀C(jī)票的盲盒活動(dòng)，它帶來(lái)的瞬時(shí)并發(fā)太高了。雖然會(huì)員系統(tǒng)安然無(wú)恙，但還是有點(diǎn)心有余悸，穩(wěn)妥起見(jiàn)，最終還是決定實(shí)施緩存方案。

| ES 近一秒延時(shí)導(dǎo)致的 Redis 緩存數(shù)據(jù)不一致問(wèn)題的解決方案

在做會(huì)員緩存方案的過(guò)程中，遇到一個(gè) ES 引發(fā)的問(wèn)題，該問(wèn)題會(huì)導(dǎo)致緩存數(shù)據(jù)的不一致。

我們知道，ES 操作數(shù)據(jù)是近實(shí)時(shí)的，往 ES 新增一個(gè) Document，此時(shí)立即去查，是查不到的，需要等待 1 秒后才能查詢(xún)到。

如下圖所示：

ES 的近實(shí)時(shí)機(jī)制為什么會(huì)導(dǎo)致 Redis 緩存數(shù)據(jù)不一致呢？具體來(lái)講，假設(shè)一個(gè)用戶(hù)注銷(xiāo)了自己的 APP 賬號(hào)，此時(shí)需要更新 ES，刪除 APP 賬號(hào)和微信賬號(hào)的綁定關(guān)系。 而 ES 的數(shù)據(jù)更新是近實(shí)時(shí)的，也就是說(shuō)，1 秒后你才能查詢(xún)到更新后的數(shù)據(jù)。

而就在這 1 秒內(nèi)，有個(gè)請(qǐng)求來(lái)查詢(xún)?cè)撚脩?hù)的會(huì)員綁定關(guān)系，它先到 Redis 緩存中查，發(fā)現(xiàn)沒(méi)有，然后到 ES 查，查到了，但查到的是更新前的舊數(shù)據(jù)。

最后，該請(qǐng)求把查詢(xún)到的舊數(shù)據(jù)更新到 Redis 緩存并返回。 就這樣，1 秒后，ES 中該用戶(hù)的會(huì)員數(shù)據(jù)更新了，但 Redis 緩存的數(shù)據(jù)還是舊數(shù)據(jù)，導(dǎo)致了 Redis 緩存跟 ES 的數(shù)據(jù)不一致。

如下圖所示：

面對(duì)該問(wèn)題，如何解決呢？我們的思路是，在更新 ES 數(shù)據(jù)時(shí)，加一個(gè) 2 秒的 Redis 分布式并發(fā)鎖，為了保證緩存數(shù)據(jù)的一致性，接著再刪除 Redis 中該會(huì)員的緩存數(shù)據(jù)。

如果此時(shí)有請(qǐng)求來(lái)查詢(xún)數(shù)據(jù)，先獲取分布式鎖，發(fā)現(xiàn)該會(huì)員 ID 已經(jīng)上鎖了，說(shuō)明 ES 剛剛更新的數(shù)據(jù)尚未生效，那么此時(shí)查詢(xún)完數(shù)據(jù)后就不更新 Redis 緩存了，直接返回，這樣就避免了緩存數(shù)據(jù)的不一致問(wèn)題。

如下圖所示：

上述方案，乍一看似乎沒(méi)什么問(wèn)題了，但仔細(xì)分析，還是有可能導(dǎo)致緩存數(shù)據(jù)的不一致。

例如，在更新請(qǐng)求加分布式鎖之前，恰好有一個(gè)查詢(xún)請(qǐng)求獲取分布式鎖，而此時(shí)是沒(méi)有鎖的，所以它可以繼續(xù)更新緩存。

但就在他更新緩存之前，線(xiàn)程 block 了，此時(shí)更新請(qǐng)求來(lái)了，加了分布式鎖，并刪除了緩存。當(dāng)更新請(qǐng)求完成操作后，查詢(xún)請(qǐng)求的線(xiàn)程活過(guò)來(lái)了，此時(shí)它再執(zhí)行更新緩存，就把臟數(shù)據(jù)寫(xiě)到緩存中了。

發(fā)現(xiàn)沒(méi)有？主要的問(wèn)題癥結(jié)就在于“刪除緩存”和“更新緩存”發(fā)生了并發(fā)沖突，只要將它們互斥，就能解決問(wèn)題。

如下圖所示：

實(shí)施了緩存方案后，經(jīng)統(tǒng)計(jì)，緩存命中率 90%+，極大緩解了 ES 的壓力，會(huì)員系統(tǒng)整體性能得到了很大提升。

| Redis 雙中心多集群架構(gòu)

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

如下圖所示：?

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

更新緩存數(shù)據(jù)時(shí)，雙寫(xiě)，只有兩個(gè)機(jī)房的 Redis 集群都寫(xiě)成功了，才返回成功。查詢(xún)緩存數(shù)據(jù)時(shí)，機(jī)房?jī)?nèi)就近查詢(xún)，降低延時(shí)。這樣，即使機(jī)房 A 整體故障，機(jī)房 B 還能提供完整的會(huì)員服務(wù)。

高可用會(huì)員主庫(kù)方案

上述講到，全平臺(tái)會(huì)員的綁定關(guān)系數(shù)據(jù)存在 ES，而會(huì)員的注冊(cè)明細(xì)數(shù)據(jù)存在關(guān)系型數(shù)據(jù)庫(kù)。

最早，會(huì)員使用的數(shù)據(jù)庫(kù)是 SqlServer，直到有一天，DBA 找到我們說(shuō)，單臺(tái) SqlServer 數(shù)據(jù)庫(kù)已經(jīng)存儲(chǔ)了十多億的會(huì)員數(shù)據(jù)，服務(wù)器已達(dá)到物理極限，不能再擴(kuò)展了。 按照現(xiàn)在的增長(zhǎng)趨勢(shì)，過(guò)不了多久，整個(gè) SqlServer 數(shù)據(jù)庫(kù)就崩了。

你想想，那是一種什么樣的災(zāi)難場(chǎng)景： 會(huì)員數(shù)據(jù)庫(kù)崩了，會(huì)員系統(tǒng)就崩了； 會(huì)員系統(tǒng)崩了，全公司所有業(yè)務(wù)線(xiàn)就崩了。 想想就不寒而栗，酸爽無(wú)比，為此我們立刻開(kāi)啟了遷移 DB 的工作。

| MySQL 雙中心 Partition 集群方案

經(jīng)過(guò)調(diào)研，我們選擇了雙中心分庫(kù)分表的 MySQL 集群方案，如下圖所示：

會(huì)員一共有十多億的數(shù)據(jù)，我們把會(huì)員主庫(kù)分了 1000 多個(gè)分片，平分到每個(gè)分片大概百萬(wàn)的量級(jí)，足夠使用了。

MySQL 集群采用 1 主 3 從的架構(gòu)，主庫(kù)放在機(jī)房 A，從庫(kù)放在機(jī)房 B，兩個(gè)機(jī)房之間通過(guò)專(zhuān)線(xiàn)同步數(shù)據(jù)，延遲在 1 毫秒內(nèi)。

會(huì)員系統(tǒng)通過(guò) DBRoute 讀寫(xiě)數(shù)據(jù)，寫(xiě)數(shù)據(jù)都路由到 master 節(jié)點(diǎn)所在的機(jī)房 A，讀數(shù)據(jù)都路由到本地機(jī)房，就近訪(fǎng)問(wèn)，減少網(wǎng)絡(luò)延遲。

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

雙中心 MySQL 集群搭建好后，我們進(jìn)行了壓測(cè)，測(cè)試下來(lái)，秒并發(fā)能達(dá)到 2 萬(wàn)多，平均耗時(shí)在 10 毫秒內(nèi)，性能達(dá)標(biāo)。

| 會(huì)員主庫(kù)平滑遷移方案

接下來(lái)的工作，就是把會(huì)員系統(tǒng)的底層存儲(chǔ)從 SqlServer 切到 MySQL 上，這是個(gè)風(fēng)險(xiǎn)極高的工作。

主要有以下幾個(gè)難點(diǎn)：

• 會(huì)員系統(tǒng)是一刻都不能停機(jī)的，要在不停機(jī)的情況下完成 SqlServer 到 MySQL 的切換，就像是在給高速行駛的汽車(chē)換輪子。

• 會(huì)員系統(tǒng)是由很多個(gè)系統(tǒng)和接口組成的，畢竟發(fā)展了 10 多年，由于歷史原因，遺留了大量老接口，邏輯錯(cuò)綜復(fù)雜。這么多系統(tǒng)，必須一個(gè)不落的全部梳理清楚，DAL 層代碼必須重寫(xiě)，而且不能出任何問(wèn)題，否則將是災(zāi)難性的。

• 數(shù)據(jù)的遷移要做到無(wú)縫遷移，不僅是存量 10 多億數(shù)據(jù)的遷移，實(shí)時(shí)產(chǎn)生的數(shù)據(jù)也要無(wú)縫同步到 MySQL。另外，除了要保障數(shù)據(jù)同步的實(shí)時(shí)性，還要保證數(shù)據(jù)的正確性，以及 SqlServer 和 MySQL 數(shù)據(jù)的一致性。

基于以上痛點(diǎn)，我們?cè)O(shè)計(jì)了“全量同步、增量同步、實(shí)時(shí)流量灰度切換”的技術(shù)方案。

首先，為了保證數(shù)據(jù)的無(wú)縫切換，采用實(shí)時(shí)雙寫(xiě)的方案。因?yàn)闃I(yè)務(wù)邏輯的復(fù)雜，以及 SqlServer 和 MySQL 的技術(shù)差異性，在雙寫(xiě) MySQL 的過(guò)程中，不一定會(huì)寫(xiě)成功，而一旦寫(xiě)失敗，就會(huì)導(dǎo)致 SqlServer 和 MySQL 的數(shù)據(jù)不一致，這是絕不允許的。

所以，我們采取的策略是，在試運(yùn)行期間，主寫(xiě) SqlServer，然后通過(guò)線(xiàn)程池異步寫(xiě) MySQL，如果寫(xiě)失敗了，重試三次，如果依然失敗，則記日志，然后人工排查原因，解決后，繼續(xù)雙寫(xiě)，直到運(yùn)行一段時(shí)間，沒(méi)有雙寫(xiě)失敗的情況。

通過(guò)上述策略，可以確保在絕大部分情況下，雙寫(xiě)操作的正確性和穩(wěn)定性，即使在試運(yùn)行期間出現(xiàn)了 SqlServer 和 MySQL 的數(shù)據(jù)不一致的情況，也可以基于 SqlServer 再次全量構(gòu)建出 MySQL 的數(shù)據(jù)。

因?yàn)槲覀冊(cè)谠O(shè)計(jì)雙寫(xiě)策略時(shí)，會(huì)確保 SqlServer 一定能寫(xiě)成功，也就是說(shuō)，SqlServer 中的數(shù)據(jù)是全量最完整、最正確的。

如下圖所示：

?講完了雙寫(xiě)，接下來(lái)我們看一下“讀數(shù)據(jù)”如何灰度。整體思路是，通過(guò) A/B 平臺(tái)逐步灰度流量，剛開(kāi)始 100% 的流量讀取 SqlServer 數(shù)據(jù)庫(kù)，然后逐步切流量讀取 MySQL 數(shù)據(jù)庫(kù)，先 1%，如果沒(méi)有問(wèn)題，再逐步放流量，最終 100% 的流量都走 MySQL數(shù)據(jù)庫(kù)。

在逐步灰度流量的過(guò)程中，需要有驗(yàn)證機(jī)制，只有驗(yàn)證沒(méi)問(wèn)題了，才能進(jìn)一步放大流量。

那么這個(gè)驗(yàn)證機(jī)制如何實(shí)施呢？方案是，在一次查詢(xún)請(qǐng)求里，通過(guò)異步線(xiàn)程，比較 SqlServer 和 MySQL 的查詢(xún)結(jié)果是否一致，如果不一致，記日志，再人工檢查不一致的原因，直到徹底解決不一致的問(wèn)題后，再逐步灰度流量。

如下圖所示： 所以，整體的實(shí)施流程如下：

首先，在一個(gè)夜黑風(fēng)高的深夜，流量最小的時(shí)候，完成 SqlServer 到 MySQL 數(shù)據(jù)庫(kù)的全量數(shù)據(jù)同步。

接著，開(kāi)啟雙寫(xiě)，此時(shí)，如果有用戶(hù)注冊(cè)，就會(huì)實(shí)時(shí)雙寫(xiě)到兩個(gè)數(shù)據(jù)庫(kù)。那么，在全量同步和實(shí)時(shí)雙寫(xiě)開(kāi)啟之間，兩個(gè)數(shù)據(jù)庫(kù)還相差這段時(shí)間的數(shù)據(jù)，所以需要再次增量同步，把數(shù)據(jù)補(bǔ)充完整，以防數(shù)據(jù)的不一致。

剩下的時(shí)間，就是各種日志監(jiān)控，看雙寫(xiě)是否有問(wèn)題，看數(shù)據(jù)比對(duì)是否一致等等。

這段時(shí)間是耗時(shí)最長(zhǎng)的，也是最容易發(fā)生問(wèn)題的，如果有的問(wèn)題比較嚴(yán)重，導(dǎo)致數(shù)據(jù)不一致了，就需要從頭再來(lái)，再次基于 SqlServer 全量構(gòu)建 MySQL 數(shù)據(jù)庫(kù)，然后重新灰度流量。

直到最后，100% 的流量全部灰度到 MySQL，此時(shí)就大功告成了，下線(xiàn)灰度邏輯，所有讀寫(xiě)都切到 MySQL 集群。

| MySQL 和 ES 主備集群方案

做到這一步，感覺(jué)會(huì)員主庫(kù)應(yīng)該沒(méi)問(wèn)題了，可 dal 組件的一次嚴(yán)重故障改變了我們的想法。

那次故障很恐怖，公司很多應(yīng)用連接不上數(shù)據(jù)庫(kù)了，創(chuàng)單量直線(xiàn)往下掉，這讓我們意識(shí)到，即使數(shù)據(jù)庫(kù)是好的，但 dal 組件異常，依然能讓會(huì)員系統(tǒng)掛掉。

所以，我們?cè)俅萎悩?gòu)了會(huì)員主庫(kù)的數(shù)據(jù)源，雙寫(xiě)數(shù)據(jù)到 ES，如下所示：

如果 dal 組件故障或 MySQL 數(shù)據(jù)庫(kù)掛了，可以把讀寫(xiě)切到 ES，等 MySQL 恢復(fù)了，再把數(shù)據(jù)同步到 MySQL，最后把讀寫(xiě)再切回到 MySQL 數(shù)據(jù)庫(kù)。

如下圖所示：

異常會(huì)員關(guān)系治理

會(huì)員系統(tǒng)不僅僅要保證系統(tǒng)的穩(wěn)定和高可用，數(shù)據(jù)的精準(zhǔn)和正確也同樣重要。

舉個(gè)例子，一個(gè)分布式并發(fā)故障，導(dǎo)致一名用戶(hù)的 APP 賬戶(hù)綁定了別人的微信小程序賬戶(hù)，這將會(huì)帶來(lái)非常惡劣的影響。

首先，一旦這兩個(gè)賬號(hào)綁定了，那么這兩個(gè)用戶(hù)下的酒店、機(jī)票、火車(chē)票訂單是互相可以看到的。

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

例如，一個(gè)用戶(hù)在 APP 的訂單中心，看到了別人訂的機(jī)票訂單，他覺(jué)得不是自己的訂單，就把訂單取消了。

這將會(huì)帶來(lái)非常嚴(yán)重的客訴，大家知道，機(jī)票退訂費(fèi)用是挺高的，這不僅影響了該用戶(hù)的正常出行，還導(dǎo)致了比較大的經(jīng)濟(jì)損失，非常糟糕。

針對(duì)這些異常會(huì)員賬號(hào)，我們進(jìn)行了詳細(xì)的梳理，通過(guò)非常復(fù)雜燒腦的邏輯識(shí)別出這些賬號(hào)，并對(duì)會(huì)員接口進(jìn)行了深度優(yōu)化治理，在代碼邏輯層堵住了相關(guān)漏洞，完成了異常會(huì)員的治理工作。

如下圖所示：

展望：更精細(xì)化的流控和降級(jí)策略

任何一個(gè)系統(tǒng)，都不能保證百分之一百不出問(wèn)題，所以我們要有面向失敗的設(shè)計(jì)，那就是更精細(xì)化的流控和降級(jí)策略。

| 更精細(xì)化的流控策略

熱點(diǎn)控制。針對(duì)黑產(chǎn)刷單的場(chǎng)景，同一個(gè)會(huì)員 id 會(huì)有大量重復(fù)的請(qǐng)求，形成熱點(diǎn)賬號(hào)，當(dāng)這些賬號(hào)的訪(fǎng)問(wèn)超過(guò)設(shè)定閾值時(shí)，實(shí)施限流策略。

基于調(diào)用賬號(hào)的流控規(guī)則。這個(gè)策略主要是防止調(diào)用方的代碼 bug 導(dǎo)致的大流量。例如，調(diào)用方在一次用戶(hù)請(qǐng)求中，循環(huán)很多次來(lái)調(diào)用會(huì)員接口，導(dǎo)致會(huì)員系統(tǒng)流量暴增很多倍。所以，要針對(duì)每個(gè)調(diào)用賬號(hào)設(shè)置流控規(guī)則，當(dāng)超過(guò)閾值時(shí)，實(shí)施限流策略。

全局流控規(guī)則。 我們會(huì)員系統(tǒng)能抗下 tps 3 萬(wàn)多的秒并發(fā)請(qǐng)求量，如果此時(shí)，有個(gè)很恐怖的流量打過(guò)來(lái)，tps 高達(dá) 10 萬(wàn)，與其讓這波流量把會(huì)員數(shù)據(jù)庫(kù)、ES 全部打死，還不如把超過(guò)會(huì)員系統(tǒng)承受范圍之外的流量快速失敗，至少 tps 3 萬(wàn)內(nèi)的會(huì)員請(qǐng)求能正常響應(yīng)，不會(huì)讓整個(gè)會(huì)員系統(tǒng)全部崩潰。

| 更精細(xì)化的降級(jí)策略

基于平均響應(yīng)時(shí)間的降級(jí)。 會(huì)員接口也有依賴(lài)其他接口，當(dāng)調(diào)用其他接口的平均響應(yīng)時(shí)間超過(guò)閾值，進(jìn)入準(zhǔn)降級(jí)狀態(tài)。

如果接下來(lái) 1s 內(nèi)進(jìn)入的請(qǐng)求，它們的平均響應(yīng)時(shí)間都持續(xù)超過(guò)閾值，那么在接下的時(shí)間窗口內(nèi)，自動(dòng)地熔斷。

基于異常數(shù)和異常比例的降級(jí)。當(dāng)會(huì)員接口依賴(lài)的其他接口發(fā)生異常，如果 1 分鐘內(nèi)的異常數(shù)超過(guò)閾值，或者每秒異常總數(shù)占通過(guò)量的比值超過(guò)閾值，進(jìn)入降級(jí)狀態(tài)，在接下的時(shí)間窗口之內(nèi)，自動(dòng)熔斷。

目前，我們最大的痛點(diǎn)是會(huì)員調(diào)用賬號(hào)的治理。公司內(nèi)，想要調(diào)用會(huì)員接口，必須申請(qǐng)一個(gè)調(diào)用賬號(hào)，我們會(huì)記錄該賬號(hào)的使用場(chǎng)景，并設(shè)置流控、降級(jí)策略的規(guī)則。

但在實(shí)際使用的過(guò)程中，申請(qǐng)了該賬號(hào)的同事，可能異動(dòng)到其他部門(mén)了，此時(shí)他可能也會(huì)調(diào)用會(huì)員系統(tǒng)，為了省事，他不會(huì)再次申請(qǐng)會(huì)員賬號(hào)，而是直接沿用以前的賬號(hào)過(guò)來(lái)調(diào)用，這導(dǎo)致我們無(wú)法判斷一個(gè)會(huì)員賬號(hào)的具體使用場(chǎng)景是什么，也就無(wú)法實(shí)施更精細(xì)的流控和降級(jí)策略。

所以，接下來(lái)，我們將會(huì)對(duì)所有調(diào)用賬號(hào)進(jìn)行一個(gè)個(gè)的梳理，這是個(gè)非常龐大且繁瑣的工作，但無(wú)路如何，硬著頭皮也要做好。

鏈接：http://www.cbww.cn/news/52552.shtml

（版權(quán)歸原作者所有，侵刪）