微信紅包系統架構的設計和優化分享

?

編者按：經過2014年一年的醞釀，2015微信紅包總量創下歷史新高，峰值1400萬次/秒，8.1億次每分鐘，微信紅包收發達10.1億次，系統整體運行平穩, 在這里我分享下微信紅包背后的技術。

講師：jeri

核心功能&目標

首先，了解下微信紅包的4個邏輯：搖/發/搶/拆。看似簡單，實現可不簡單再review下微信紅包要實現目標：

搖：搖的流暢

快：搶的要快

爽：拆的爽

穩：能分享出去

系統難點：

1.中國運營商網絡環境復雜，覆蓋面廣，春節期間網絡吃緊，容易出現網絡故障

2.在尖峰搖時如何避免服務雪崩

3.在服務資源有限時，如何提供柔性服務

4.如何構造有損服務

5.如何構造set模型

6.如何解決并發搶

7.如何實現實現數據一致性

系統整體架構圖

跨區域網絡解決方案

微信客戶端分布全球，接入點較多，用戶資料靠近接入點，可以加速用戶資料訪問，但是紅包的業務邏輯層并不全網分布，業務邏輯層訪問數據層比較多，數據層有狀態強一致性問題，只能同用一個數據副本，比如上海用戶與深圳用戶在同個群里，搶同一個紅包，如果訂單數據在上海與深圳都有，在搶的時候，無法保證數據同步，可用性低，所以，設計系統時，一定要梳理清楚系統間的調用關系，優化接入層的業務邏輯，把網絡耗時降到最小，系統吞吐量才能提升。

跨區域網絡問題，在物理實施上，也需要有備份繞行的能力，這個可以在系統的底層框架中實現，當指定專線出現故障時，快速切換網絡，恢復服務

如何構建有損服務

什么是有損服務？選擇性犧牲一部分數據一致性和完整性從而保證核心功能絕大多數運行，經過一段時間窗口，數據一致性與完整性能得以恢復，這也是騰訊的一直運營策略，在有限資源前提下，量力而為，滿足用戶的核心需求

比如，春晚搖一搖，我們的核心點是搖/拆/分享，那系統的資源優先需要保證這些服務的響應，任何關聯系統出現異常的時候馬上進行系統降級，防止引起系統雪崩。

系統降級可以分為兩個方面，一是把核心功能調用鏈路簡化，減少依賴，通過輔助輕量化的服務實現，確保最短關鍵路徑的可行，比方說在接入層置入搖紅包邏輯，將每秒千萬級請求轉化為每秒萬級的紅包請求，再傳到紅包服務的后端邏輯，降低雪崩的可能性。

柔性服務.打造好的產品體驗

柔性可用是在有損服務價值觀支持下的方法，重點在于實際上會結合用戶使用場景，根據資源消耗，調整產品策略，設計幾個級別不同的用戶體驗場景，保證盡可能成功返回關鍵數據，并正常接受請求，絕不輕易倒下。

比如，紅包的核心功能拆，拆完需要記錄用戶頭像昵稱，轉帳資金劃轉，同時輸出同個訂單下其它拆記錄，拆過程這些操作都可能失敗，但是核心操作獲取紅包是成功的，此時，我們至少可以告訴用戶搶到金額，不至于讓用戶焦急等待，不斷重試，未完成的操作(頭像補全與資金轉帳)，可以通異步補嘗方式重試。這樣解決了用戶的問題，也緩解了系統壓力。

如果構造set模型

Set模塊就像一個集裝箱，把各模塊標準化，模塊化，規模化，它為海量服務運營，特別是設備管理、網絡架構，提供了宏觀運營支撐框架，從而極大提高了海量服務運營效率。

微信紅包的set模塊，以拆服務為例，從接入層開始，數據開始sticky，按訂單號路由，即按單號分set，同一個set盡可能在一個IDC 里，減少模塊間調用的耗時，在同一個set內，邏輯層任何一臺機器，調用方可實時摘除，如果是數據層發生故障，先在接入層，把新產生的紅包訂單號屏蔽有故障對應的set編號，比如，set1 數據庫出現故障，為了避免在故障的set1 上繼續產生新的支付請求，在訂單生成器直接跳過set1的單號規則，把新請求導致其它set, 只有未搶完的部分紅包，會提示故障，稍后恢復，阻止了故障引發的進一步惡化，在故障db上的數據，通過備機與業務邏輯層的數據核對，完成數據一致性的修復。

如何解決并發搶

群里紅包的規則是金額隨機搶，在一個大群發一個紅包出去，搶并發請求量高，在同一個資源上操作，需要增加鎖操作，避免一個搶總數超過發送紅包總數，眾所周所，mysql的加鎖操作，很多搶在一個鎖上等，性能損耗大，吞吐量下降，對于海量服務的操作，是不能滿足要求。

在set模塊的基礎上，我們把發/搶的資源請求都會落到同一個資源set，在最外層，cache紅包的狀態，如果紅包已經被搶完了，即刻返回，如果紅包未接完，對于一個紅包進去搶環節還有限流，這是第一級保護，通過一致性hash算法，一一個單到dao層都會路由到同一個機器的同一個進程，dao到mysql在現一個連接上完成搶操作，把并發搶修改成串行化，mysql可以無鎖等待，性能明顯提升。

如何實現數據一致性

談到分布式系統，先回顧CAP理論

C：Consistency數據一致更新，所有變動都是同步的

A：高可用，好的響應性能

P: 分區容忍，可靠性

在我們的系統設計中，同樣碰到這個問題，無法同時滿足三個因子，移動互聯網系統，高可用性是必要要求，數據分區也是分布式系統的條件，所以，我們設計系統時，只能盡量保證數據一致性，只要一定時間窗口內，完成數據一致，讓用戶滿意。

微信紅包的數據有幾份，訂單數據，用戶數據，還有對應的cache數據，

N：數據副本份數紅包有三份

R: 一次需讀取的副本紅包一次從一個副本可以全部讀取需要數據

W: 一次寫入數據2份實時寫，一分異步化

R(1) + W(2) <=N從公式算出，我們的數據模型也是弱一致性

用戶數據是異步更新，更新失敗，通過消息中心，異步重試，根據DB資源負載設置調用方的調用閥值，除了實時重試，我們還有準實時數據核對，保證數據最終一致性。