微信紅包設計方案

前言

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

紅包系統

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

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

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

爲處理高峯期的搖一搖和支付邏輯，避免複雜邏輯及事務處理耗時較長，將搖一搖和紅包到帳按異步邏輯處理。 同時爲下降搶紅包後寫DB的耗時，將紅包信息票據進行加密放到客戶端，經過本地計算完成搶紅包過程。 後續的結算邏輯放入消息隊列中，經過異步方式進入結算系統，完成後續工做。

大規模集羣中保證數據一致性

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

系統可用性

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

• 方案一：預紅包數據提供部署給微信的接入機和寫入紅包DB，搖紅包過程由紅包接入機控制紅包的發放，拆紅包時修改紅包DB中的紅包數據；
• 方案二：預紅包數據只提供部署給微信接入機，搖紅包過程由紅包接入機控制紅包的發放，拆紅包直接Insert到紅包DB。 第二個方案減小一次DB操做，若是是百億量級的紅包數據，能夠極大減小數據導入、對帳等活動準備時間，特別是方案須要變動時。