社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實現(xiàn)高可用性的

Posted on 2025-01-15 11:19 Jack Jiang 閱讀(153) 評論(0) 編輯收藏

本文來自微信團隊工程師方樂明的技術(shù)分享，由InfoQ編輯發(fā)布，下文有修訂和改動。

一、引言

微信紅包業(yè)務量級的高速發(fā)展，對后臺系統(tǒng)架構(gòu)的可用性要求越來越高。在保障微信紅包業(yè)務體驗的前提下，紅包后臺系統(tǒng)進行了一系列高可用方面的優(yōu)化設計。

本次分享介紹了微信紅包后臺系統(tǒng)的高可用實踐經(jīng)驗，主要包括后臺的 set 化設計、異步化設計、訂單異地存儲設計、存儲層容災設計與平行擴縮容等。聽眾可以了解到微信紅包后臺架構(gòu)的設計細節(jié)，共同探討高可用設計實踐上遇到的問題與解決方案。

補充說明：本文對應的演講PPT詳見《微信紅包系統(tǒng)可用性設計實踐(PPT) [附件下載]》。

技術(shù)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發(fā)布于：http://www.52im.net/thread-2564-1-1.html）

二、分享者

方樂明：現(xiàn)任微信支付應用產(chǎn)品系統(tǒng)負責人，主要從事微信紅包、微信轉(zhuǎn)賬、微信群收款等支付應用產(chǎn)品的系統(tǒng)設計、可用性提升、高性能解決方案設計等，曾連續(xù)多年負責春節(jié)微信紅包系統(tǒng)的性能優(yōu)化與穩(wěn)定性提升，取得良好的效果。

三、系列文章

系列文章目錄：

《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實現(xiàn)等》
《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進》
《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細節(jié)》
《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應對高并發(fā)的》
《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實現(xiàn)高可用性的》（* 本文）
《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲層架構(gòu)演進實踐》
《社交軟件紅包技術(shù)解密(七)：支付寶紅包的海量高并發(fā)技術(shù)實踐》
《社交軟件紅包技術(shù)解密(八)：全面解密微博紅包技術(shù)方案》
《社交軟件紅包技術(shù)解密(九)：談談手Q春節(jié)紅包的設計、容災、運維、架構(gòu)等》
《社交軟件紅包技術(shù)解密(十)：手Q客戶端針對2020年春節(jié)紅包的技術(shù)實踐》
《社交軟件紅包技術(shù)解密(十一)：最全解密微信紅包隨機算法(含演示代碼)》
《社交軟件紅包技術(shù)解密(十二)：解密抖音春節(jié)紅包背后的技術(shù)設計與實踐》
《社交軟件紅包技術(shù)解密(十三)：微信團隊首次揭秘微信紅包算法，為何你搶到的是0.01元》

四、微信紅包介紹

微信紅包從 2014 年開始發(fā)展到現(xiàn)在，中間經(jīng)歷了幾年時間。在這幾年的時間里，整個系統(tǒng)可用性產(chǎn)生了很大的提升。2015 年年初的時候，每天晚上九點鐘是微信紅包的業(yè)務高峰期，系統(tǒng)經(jīng)常性地出現(xiàn)性能問題。到了今天，即使在節(jié)假日高峰期，系統(tǒng)也不會出現(xiàn)問題。

▲ 紅包印象 – 產(chǎn)品形態(tài)（點此查看本圖出處）

如上圖所示，微信紅包的業(yè)務包含包、發(fā)、搶、拆、查詢發(fā)送紅包和收紅包數(shù)量，其中最關(guān)鍵的步驟是發(fā)紅包和搶紅包。

微信紅包是微信支付的商戶，微信紅包這個商戶出售的是錢。發(fā)紅包用戶在微信紅包平臺使用微信支付購買一份錢，微信紅包將錢發(fā)放到相對應的微信群。群里的用戶搶紅包得到微信零錢。這個過程中，微信紅包和微信支付之間的關(guān)系是商家和第三方支付平臺的關(guān)系。

微信紅包和微信支付之間的交互，與普通商家與微信支付的交互一樣，需要經(jīng)過六個步驟。用戶發(fā)紅包時，進入微信紅包下一筆訂單，系統(tǒng)記錄發(fā)紅包用戶、發(fā)紅包金額、紅包數(shù)量和要發(fā)送到的用微信群。然后微信紅包系統(tǒng)請求微信支付服務器進行下單，用戶使用微信支付進行支付。

支付成功后，微信支付后臺系統(tǒng)通知微信紅包后臺系統(tǒng)支付成功結(jié)果，微信紅包后臺系統(tǒng)收到通知后推送微信紅包消息到微信群。微信群里用戶便可搶紅包。這就是微信紅包和微信支付的關(guān)系以及交互過程。

五、微信紅包系統(tǒng)架構(gòu)

5.1 微信紅包的系統(tǒng)流程

▲ 微信紅包的系統(tǒng)流程（點此查看本圖出處）

上圖是微信紅包系統(tǒng)角度上的流程，業(yè)務主流程是包、發(fā)、搶、拆四個操作，每個操作包括幾個關(guān)鍵步驟。

包紅包：系統(tǒng)為每個紅包分配一個唯一 ID，即紅包發(fā)送訂單號，然后將發(fā)紅包用戶、紅包個數(shù)、紅包數(shù)額寫入存儲，最后去微信支付下單。

發(fā)紅包：用戶使用微信支付完成付款，微信紅包后臺系統(tǒng)收到微信支付系統(tǒng)的支付成功通知。紅包系統(tǒng)將紅包發(fā)送訂單狀態(tài)更新為用戶已支付，并寫入用戶發(fā)紅包記錄（用戶發(fā)紅包記錄，就是微信錢包中，查看到的用戶每一年總共發(fā)出及收到的紅包記錄）。最后微信紅包后臺系統(tǒng)發(fā)送微信紅包消息到微信群。

搶紅包：指微信群里的用戶收到微信紅包消息后，點開紅包消息。這個過程，微信紅包后臺系統(tǒng)會檢查紅包是否已被搶完，是否已過期，是否已經(jīng)搶過。

拆紅包是最復雜的業(yè)務是操作，包括：

1）查詢這個紅包發(fā)送訂單，判斷用戶是否可拆，然后計算本次可拆到的紅包金額；
2）然后寫入一條搶紅包記錄。如果把拆紅包過程，類比為一個秒殺活動的過程，相當于扣庫存與寫入秒殺記錄的過程；
3）更新庫存對應于更新紅包發(fā)送訂單，寫入秒殺記錄對應于寫入這個紅包的領(lǐng)取紅包記錄；
4）另外，還要寫入用戶整體的紅包領(lǐng)取記錄；
5）最后請求微信支付系統(tǒng)給拆到紅包用戶轉(zhuǎn)入零錢，成功后更新?lián)尲t包的訂單狀態(tài)為已轉(zhuǎn)賬成功。

5.2 微信紅包的整體架構(gòu)

▲ 微信紅包的系統(tǒng)架構(gòu)（點此查看本圖出處）

上圖所示，是微信紅包的系統(tǒng)架構(gòu)。包括微信統(tǒng)一接入層，下面是微信紅包系統(tǒng) API，包括發(fā)、搶、拆、查紅包詳情、查紅包用戶列表。再下面是封裝微信紅包關(guān)鍵業(yè)務的邏輯服務；最下面一層是數(shù)據(jù)存儲層，微信紅包最主要的數(shù)據(jù)是訂單數(shù)據(jù)，包括發(fā)紅包訂單和拆紅包訂單兩部分。業(yè)務邏輯和存儲服務器之間是數(shù)據(jù)接入層，它最重要的作用是封裝數(shù)據(jù)庫操作的領(lǐng)域邏輯，使得業(yè)務邏輯服務不需要感知對 MySQL 的連接管理、性能、容災等問題。

微信紅包數(shù)據(jù)的訪問熱度，隨著時間流逝會急劇降低，也就是數(shù)據(jù)的訪問時間段非常集中，一般紅包發(fā)出三天后，99% 的用戶不會再去點開這個紅包了。因此微信紅包系統(tǒng)采取按時間做冷熱數(shù)據(jù)分離，降低數(shù)據(jù)的存儲成本，同時提升了熱數(shù)據(jù)的訪問性能。

數(shù)據(jù)平臺用于對紅包數(shù)據(jù)的分析計算，比如朋友圈里的文章，統(tǒng)計從某年 1 月 1 日到 2017 年 1 月一個用戶總共搶紅包的金額，在全國的排名情況，發(fā)紅包數(shù)最多的城市等。另外一個作用就是對賬，紅包的訂單和微信支付的訂單需要對賬，以保證最終資金的一致性；訂單的數(shù)據(jù)和訂單的 cache 需要做對賬，以保證數(shù)據(jù)的完整性；訂單數(shù)據(jù)和用戶的收發(fā)記錄需要對賬，以保證用戶列表完整性。

六、微信紅包系統(tǒng)可用性實踐

6.1系統(tǒng)可用性影響因素

系統(tǒng)的可用性影響因素可分成兩類：

一類計劃外；
一類計劃內(nèi)。

計劃外包含很多因素，系統(tǒng)用到的所有東西都可能產(chǎn)生故障，都可能成功影響可用性的因素。從這個角度上來講，可以說故障是無法避免的，系統(tǒng)的運作一定會產(chǎn)生故障，尤其是服務器有成千上萬個的時候。計劃內(nèi)的影響因素，主要有與升級相關(guān)、運維相關(guān)的操作，以及日常的備份等。這一類影響因素，通過精細地設計方案，是可以避免對可用性造成影響的。

6.2微信紅包系統(tǒng)可用性設計方向

基于上面兩個分析結(jié)論，可以總結(jié)出微信紅包后臺系統(tǒng)的可用性的設計方向。就是在不能避免意外故障的情況下，盡可能降低出現(xiàn)意外故障時對可用性的影響。另一方面，絕大多數(shù)計劃內(nèi)的日常維護可以通過方案的設計避免影響可用性，其中平行擴容特指關(guān)于存儲層的平行擴容。

下面從降低故障影響和微信紅包系統(tǒng)的平行擴容兩方面進行分析。

首先是降低意外故障的影響，重點講解訂單存儲層在訂單 DB 故障的情況下如何降低對紅包系統(tǒng)可用性的影響。

6.3業(yè)務邏輯層 - 部署方案設計

首先是業(yè)務邏輯層的部署方案。業(yè)務邏輯層是無狀態(tài)的，微信紅包系統(tǒng)的業(yè)務邏輯層，部署在兩個城市，即兩地部署，每一個城市部署至少三個園區(qū)，即三個 IDC。并且每個服務需要保證三個 IDC 的部署均衡。另外，三個 IDC 總服務能力需要冗余三分之一，當一個 IDC 出現(xiàn)故障時，服務能力仍然足夠。從而達到 IDC 故障不會對可用性產(chǎn)生影響。

6.4業(yè)務邏輯層 - 異步化設計

▲ 業(yè)務邏輯層 – 異步化（點此查看本圖出處）

第二是異步化設計。如上圖所示，微信紅包的某些步驟不實時完成也不會影響用戶對紅包業(yè)務可用性的體驗。比如拆紅包，正常的業(yè)務流程很長，但關(guān)鍵步驟只有訂單相關(guān)的幾步。至于轉(zhuǎn)零錢、寫紅包記錄等操作不需要實時。用戶搶到紅包時，一般不會實時去錢包查看微信零錢，而是在微信群中點開消息查看本次搶到金額和他人搶紅包金額。所以拆紅包時只需要從 cache 查詢用戶是否拆過紅包，然后寫入拆紅包的訂單記錄，更新發(fā)紅包訂單，其他的操作都可以異步化。當然，不是每個業(yè)務都可以進行異步化設計，需要進行業(yè)務分析，判斷是否存在非關(guān)鍵步驟之外的事情可以將其異步化，并通過異步對賬保證最終一致。

▲ 訂單存儲層 – 早期架構(gòu)（點此查看本圖出處）

接下來是微信紅包訂單存儲設計。上圖是 2014 年微信紅包存儲層的模型。業(yè)務邏輯層請求數(shù)據(jù)層操作時，使用訂單號 hash 路由到訂單 SERVER。訂單 SERVER 與每一組 MYSQL 數(shù)據(jù)庫連接。

微信紅包的訂單號是在發(fā)紅包時系統(tǒng)生成唯一標識，使用序列號服務生成唯一 ID，后面拼接三位微信紅包的訂單分庫表的標識。所以，總共可以分一百個邏輯庫，每個邏輯庫含有十張表。一百個邏輯庫均勻地分布到十組物理 DB，每組 DB 存十個邏輯庫。

這個架構(gòu)的最大問題是，一組 DB 故障時，會影響其他 DB。2014-2015 年期間，微信紅包量漲得特別快，擴容速度跟不上業(yè)務增長速度。一組 DB 的性能出現(xiàn)瓶頸時，數(shù)據(jù)操作變慢, 拆紅包的事務操作在 MYSQL 排隊等待。由于所有十組 DB 機器與所有的訂單 SERVER 連接，導致所有的訂單 SERVER 都被拖住，從而影響紅包整體的可用性。這個架構(gòu)的另一個問題是擴容不方便，后面會介紹。

為解決 DB 間的相互影響，需要將 DB 間相互隔離，訂單存儲層 SET 化。SET 化指訂單 DB 和訂單接入 SERVER 垂直 stick 一起。業(yè)務邏輯層訪問訂單時，根據(jù)訂單倒數(shù)第二、三位數(shù)字找到所屬訂單 SET，一個 SET 的請求不能路由到其他 SET。

找到對應的訂單接入服務器之后，在服務器內(nèi)的多個進程中找到指定進程，讓同個紅包的所有拆請求串行化。當一組 DB 出現(xiàn)故障，只會影響該組 DB 對應的 SERVER。

這里有一個問題，DB 故障拖住某些訂單 SERVER，會不會也拖住更上層業(yè)務邏輯服務？業(yè)務邏輯層為什么不一起 SET 化？業(yè)務邏輯層承載了用戶維度相關(guān)的業(yè)務操作，不可以按照訂單的維度分業(yè)務邏輯，例如務邏輯層會請求用戶的頭像、昵稱等，如果繼續(xù)按照訂單分業(yè)務邏輯，會導致跨地域調(diào)用。

微信紅包系統(tǒng)采取的方案是，在訂單 SERVER 服務端增加快速拒絕服務的能力。SERVER 主動監(jiān)控 DB 的性能情況，DB 性能下降、自身的 CPU 使用升高，或者發(fā)現(xiàn)其他的監(jiān)控維度超標時，訂單 SERVER 直接向上層報錯，不再去訪問 DB，以此保證業(yè)務邏輯層的可用性。

一組 DB 故障不會影響整個系統(tǒng)的可用性。有影響的，只有十分之一，若擴成 100 組，影響便只有一百分之一。所以通過 SET 化得到的好處是，控制 DB 連接數(shù)、隔離故障影響和分流并發(fā)。

▲ 訂單存儲層 – 故障自愈（點此查看本圖出處）

完成 SET 化之后，DB 故障仍對業(yè)務有十分之一影響，那么這十分之一該怎么解決？通過對系統(tǒng)進行研究分析之后，發(fā)現(xiàn) DB 可以做到故障自愈。

如上圖所示，所設尾號 90-99 的 SET 故障時，如果業(yè)務邏輯服務后續(xù)不再生成屬于這個 SET 的訂單，那后續(xù)的業(yè)務就可以逐漸恢復。

也就是在發(fā)生故障時，業(yè)務邏輯層發(fā)布一個版本，屏蔽故障號段的單號生成，就可以恢復業(yè)務。進一步想，除了人為發(fā)版本，有沒有方法可以讓 DB 故障時自動恢復？在 DB 故障導致業(yè)務失敗時，業(yè)務邏輯層可獲取到故障 DB 的號段，在發(fā)紅包時，將這些故障的號段，換一個可用的號段就可恢復業(yè)務。訂單號除了最后三位，前面的部分已能保證該紅包唯一性，后面的數(shù)字只代表著分庫表信息，故障時只需要將最后三位換另外一個 SET 便可自動恢復。

完成這個設計后，即使 DB 出現(xiàn)故障，業(yè)務的可用性也不會有影響。這里還有一點，新的發(fā)紅包請求可避免 DB 故障的影響，但那些故障之前已發(fā)出未被領(lǐng)取的紅包，紅包消息已發(fā)送到微信群，單號已確定，拆紅包時還是失敗。對這種情況，由于不會有增量，采用正常的主備切換解決即可。

6.5平行擴縮容設計

▲ 平行擴縮容 – 早期方案（點此查看本圖出處）

上圖是微信紅包早期的擴縮容方式。這個擴容方式，對擴容的機器數(shù)有限制。前面講到，紅包系統(tǒng)按紅包單號后面兩個數(shù)字分多 SET，為了使擴容后數(shù)據(jù)保持均衡，擴容只能由 10 組 DB 擴容到 20 組、50 組或者 100 組。另外，這個擴容方式，過程也比較復雜。首先，數(shù)據(jù)要先從舊數(shù)據(jù)庫同步復制到新擴容的 DB，然后部署 DB 的接入 SERVER，最后在凌晨業(yè)務低峰時停服擴容。

這個擴容方式的復雜性，根本原因是數(shù)據(jù)需要從舊 SET 遷到新 SET。如果新產(chǎn)生數(shù)據(jù)與舊數(shù)據(jù)沒關(guān)系，那么就可以省掉這部分的遷移動作，不需停服輸。分析發(fā)現(xiàn)，需要把舊數(shù)據(jù)遷出來的原因是訂單號段 00-99 已全部被用，每個物理數(shù)據(jù)庫包含了 10 個邏輯庫。如果將訂單號重新設計，預留三位空間，三位數(shù)字每一個代表獨立的物理 DB，原來 10 組 DB 分別為 000-009 號段。

這種設計，縮容時，比如要縮掉 000 這組，只需在業(yè)務邏輯服務上不生成訂單號為 000 的紅包訂單。擴容時，比如擴為 11 組，只需多生成 010 的訂單號，這個數(shù)據(jù)便自動寫入新 DB。當然，縮容需要一個前提條件，也就是冷熱分離，縮容后數(shù)據(jù)變?yōu)槔鋽?shù)據(jù)，可下線熱數(shù)據(jù)機器。以上就是紅包的平行擴縮容方案。