編者按

與傳統意義上的紅包相比，近兩年火起來的“紅包”，似乎才是如今春節的一大重頭戲。歷經上千年時代傳承與變遷，春節發紅包早已成為歷史沉淀的文化習俗，融入了民族的血脈。按照各家公布的數據，除夕全天微信用戶紅包總發送量達到10.1億次，搖一搖互動量達到110億次，紅包峰值發送量為8.1億次/分鐘。而支付寶的紅包收發總量達到2.4億次，參與人數達到6.83億人次，紅包總金額40億元，峰值為8.83億次/分鐘。春晚直播期間討論春晚的微博達到5191萬條，網友互動量達到1.15億，網友搶微博紅包的總次數超過8億次。

為此，InfoQ策劃了“春節紅包”系列文章，以期為讀者剖析各大平臺的紅包活動背后的技術細節。本文為微博篇。

隨著互聯網的發展，打破了以往傳統的發紅包，帶給了紅包全新的玩法。微博紅包已經成為用戶給粉絲拜年的一種途徑，土豪版成為土豪刷存在感的方式。每年的紅包大戰都是用戶的現金盛宴，對于整個系統卻是殘酷的考驗。

微博有8億注冊用戶，單日活躍用戶數1.34億的社交平臺。紅包在微博平臺上運行，針對所有的微博用戶開放，微博所有用戶都可參與紅包活動。微博紅包有如下特點：

1. 紅包價值高、種類多、覆蓋用戶廣，億級別用戶參與。

2. 半點準時開搶，高并發訪問、瞬間峰值高，每分鐘帶來上億次的搶紅包峰值。

3. 請求快速響應，更新億級用戶中獎狀態及紅包狀態。

4. 單個紅包數額大。

春晚當天紅包總價值超過10億，有1.34億用戶參與，產生了8億多次的搶紅包行為，其中并發量為平時峰值的10倍左右。在服務器數量一定的情況下，如何構建高并發操作、瞬間峰值高的穩定服務？對于團隊和架構師都是一個極大的挑戰。這時候系統的架構尤為重要！

紅包架構

微博紅包支持每秒幾十萬次的操作，應對突發性的熱點事件，快速響應，高內聚低耦合的服務成了架構首先要考慮的因素。

(點擊放大圖像)

微博是社交型應用，紅包在用戶數據、關系、搶紅包等結構上存在著各種各樣復雜的依賴，這些依賴相比其它應用來說，調用頻率更高，性能要求也更高。

如上圖所示，有多個應用模塊接入紅包的服務層，服務層由多個節點組成，每個節點對應相應的功能并且相對獨立。代碼模塊的使用和組織上相對獨立，保證主功能的快速和穩定，將附屬的新功能分離在獨立模塊中。其中紅色虛線框內為核心的功能模塊，是重點需要保護的功能。

微博紅包提供獲取紅包屬性（紅包金額、紅包設置、紅包狀態、獲取抽取結果列表、拆包，抽獎等）接口。服務層調用紅包SDK相應的API，會根據應用層邏輯需求提供數據和定制化得數據，完成前端完成交互，達到應用層需要展現的效果。

?

防刷策略

微博紅包有別于微信用戶發出的紅包，微信用戶發出的紅包是針對自己所認識的朋友或者已存在于微信群的用戶；微博紅包是針對于微博所有用戶的紅包，通過分析參與紅包的用戶數據每年都會產生一些囤積大量賬號準備在春晚大發橫財的公司和個人。如何防止微博紅包被自動注冊或者通過轉賣賬號來領取紅包？這成為面對我們需要解決的一大問題。

(點擊放大圖像)

微博通過基于用戶在微博上的行為分析，通過登錄，發微博，身份驗證等方面來進行分析。主要有：

1. 用戶注冊：通過用戶行為分析來識別機器注冊的用戶，則注冊環節進行攔截。

2. 用戶登錄：分析用戶登錄的行為，通過驗證碼，身份驗證以及手機號驗證等措施來提高機器自動登錄的門檻。

3. 賬號質量：通過實名認證，微博的動態等方面來計算出用戶的質量。

4. 參與紅包：紅包戰場一貫是刷獎賬號的獲利主戰場， 通過用戶平時在微博的行為、屬性以及實時的登錄狀態和常用設備來進行分析，判斷是否是正常賬號來確定是否可以中獎。

完善的監控

紅包系統是一個大而規則復雜的系統，系統越大，依賴的資源越多，也就越容易出現各種各樣的問題。為了給提供穩定運行的服務，必須要能時刻知曉各個資源當前的運行狀態。并且在系統出現異常之前或者出現異常的時候，對問題進行排查和定位。

(點擊放大圖像)

如上圖所示，完善的監控系統，為微博紅包順利度過春晚提供了很好的保障。主要涉及的監控如下：

1、應用層接口響應時間監控

通過實時的分析access log日志，以HTTP code和響應時間維度實時統計出接口的狀態和性能，根據占比來查看接口的健康程度。

2、服務層各模塊性能監控

在模塊中記錄開始時間和結束時間，每次處理完計算出模塊的耗時，通過這種方式很好的發現各個模塊是否正常。????

3、網絡層監控

微博紅包的出口網絡是一個單獨的app池，出口帶寬使用到80%的時候網絡穩定性就可能受到影響。通過計算后端服務器輸出計算出帶寬，以便能夠做到及時響應擴容。

4、資源層的監控

對各種資源的監控，比如Redis、MySQL、MC等資源的連接時間、狀態和操作的實時統計分析，快速定位是否存在資源瓶頸。

5、服務器的性能監控

通過運維監控系統，對服務器的CPU、內存使用情況，做到了能夠觀察每臺服務器具體的運行情況。

6、系統錯誤日志的監控

系統錯誤監控包括服務器負載，服務進程狀態，資源連接，網絡連接出現的問題，實時通過手機，郵件和私信知道。為快速響應創造了條件。

?

彈性資源管理和調度

1、故障的秒級切換

微博紅包服務部署在了三個機房（包括云服務），任何一個機房如果出現網絡或者其它不可預測的問題可以在幾秒鐘之內將服務切換到其它機房。

2、資源的相互獨立

資源的相互獨立，讓資源的可擴展性變得容易。而且使得各個服務之間交叉影響達到了最小。

3、引入阿里云做為第三機房，使用Docker快速部署服務

紅包的核心服務主要分布在 2 個機房，兩者互相做為災難備份用途，為應對超預期的峰值，引入阿里云做為第三機房。使用定制化的紅包Docker快速部署服務來實現彈性調度架構。通過Docker自動化操作大規模集群，進行彈性調度資源的任務，實現快速部署服務來應付超預期的峰值。

系統的挑戰和性能優化

為了保證用戶體驗，微博紅包需要解決以下幾個問題：

1. 系統性能的可靠性

2. 關鍵節點的可用性

3. 如何應對突發熱點

4. 業務頻繁迭代的處理

1、系統架構的升級

模塊的獨立化，避免出現模塊間的相互影響。

nginx+lua的使用，使得服務器的QPS有了數量級的提升，同時服務器集群做到了秒級重啟。

2、修枝剪頁

減少對于系統外部的依賴，梳理完整的調用關系圖。非核心功能使用異步調用，合并相關的調用，去掉重復的調用。保證核心調用邏輯，避免非核心業務影響核心業務。

3、多級緩存

服務端本地緩存，使用nginx本身緩存和服務器的L0緩存，來提升模塊的響應速度，做到了90%以上核心接口的響應時間在50ms以內，減少了進程等待時間，提升了服務器的處理速度。

一年一度的各大平臺搶紅包還會延續下去，這是一個斗智斗勇的過程，在服務器有限的情況下每一次與峰值的對抗都是對技術一次極大的挑戰，每次挑戰都是帶來技術上的成長和收獲。

感謝郭蕾對本文的策劃和審校。

給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關注我們。