前言

微信紅包一經推出，春節期間微信使用者紅包總髮送量達80.8億，紅包峰值40.9w/秒，在如此量級下，系統設計存在各種變數，稍有閃失會功虧一簣。

紅包系統

紅包系統有三部分組成：資訊流，業務流，資金流。 對應的後臺系統包括，微信後臺，支付後臺，財付通後臺。

紅包架構包括三方面：資源預下載，搖一搖，拆紅包。

在搖一搖之前，會先將資源推送到本地客戶端。

為處理高峰期的搖一搖和支付邏輯，避免複雜邏輯及事務處理耗時較長，將搖一搖和紅包到賬按非同步邏輯處理。 同時為降低搶紅包後寫DB的耗時，將紅包資訊票據進行加密放到客戶端，通過本地計算完成搶紅包過程。 後續的結算邏輯放入訊息佇列中，通過非同步方式進入結算系統，完成後續工作。

大規模叢集中保證資料一致性

為保證系統可用性，紅包系統在多個獨立資料中心進行部署，可以達到在任意一個園區機房故障後，對外提供服務。 多園區的關鍵是資料一致性，需要維護強一致性副本，這樣可以無損提供服務。 微信採用Quorum演算法，對資料有強一致保證的儲存系統。三園區的強一致性保證採用可靠佇列。

系統可用性

進行系統容量評估，結合業務設計合理配額方案及降級方案，儘可能保證系統不過載。 如果出現過載，系統需具有自我保護能力，不擴散到其他服務，如果處理不過來，按請求優先順序丟棄超載請求。 減少核心路徑涉及的步驟和模組，集中力量保證關鍵路徑可用性。 系統監控，對真實負載有所瞭解，建立核心指標觀察，系統暫時不可用，通過重試自動解決。 在系統設計之前，評估系統2000w/s的qps峰值請求，系統實現上有一定預估量，評估值為2.5倍（5kw/s qps），大部分時間低於峰值，如果超過閾值，客戶端及服務端進行流控降級。

• 方案一：預紅包資料提供部署給微信的接入機和寫入紅包DB，搖紅包過程由紅包接入機控制紅包的發放，拆紅包時修改紅包DB中的紅包資料；
• 方案二：預紅包資料只提供部署給微信接入機，搖紅包過程由紅包接入機控制紅包的發放，拆紅包直接Insert到紅包DB。 第二個方案減少一次DB操作，如果是百億量級的紅包資料，可以極大減少資料匯入、對賬等活動準備時間，特別是方案需要變更時。