2015年微信紅包書寫了一個全新奇蹟——除夕搖一搖總次數110億次，峰值1400萬次/秒，8.1億次每分鐘，微信紅包收發達10.1億次！驚人數字的背後，騰訊是怎麼支撐的？筆者有幸節前採訪到微信後臺技術負責人，與大家分享紅包背後的技術。

春晚當天，微信紅包聯合團隊徹夜加班全程守護

400倍的挑戰

今年微信紅包方式與去年使用者與用戶之間互發紅包相比，搖紅包的方式對業務量來說是一個極大的爆發，光是除夕10：30送出的一波紅包就達到了1.2億個，已經是2014年除夕夜峰值的400倍之巨（2014年峰值每分鐘被拆開紅包數量僅2.5W個）！

進入搶紅包環節，後臺資料瞬間飆升

發10億紅包，難在哪裡？

微信團隊總結下來有三大難點：

快——如何保證使用者快速搖到紅包？

準——如何保證搖到的紅包能成功拆開？

穩——如何保證拆開的紅包能分享出去？

大量使用者在同一時間搖紅包，瞬間產生每秒千萬級的請求，這個量級的請求如果不加以疏導處理直接到達後臺，必定會導致後端服務過載甚至崩潰。上文中除夕當天後臺監控資料曲線便能說明一切——在前臺重重的分流減壓下，後臺伺服器負載仍然瞬間飆升十倍以上。

三大應對策略齊上陣

對於以上三個難點，微信後臺開發團隊主要通過三大應對策略應對：有損服務，柔性可用，大系統小做

• 有損服務-追求高可用和快速響應。

什麼是有損服務？有損服務是通過精心拆分產品流程，選擇性犧牲一部分資料一致性和完整性從而保證核心功能絕大多數執行。這是騰訊在PC時代積累下來的一種特色運營策略——在資源一定的前提下，網際網路條件千變萬化的場景中，量力而為，滿足使用者的核心需求。

微信紅包的核心點是搖，拆，分享紅包，整個系統設計時必須盡最大可能保證這三個步驟一氣呵成，任何關聯絡統出現異常的時候馬上進行系統降級，防止引起系統雪崩。

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

同時後端採用非同步分拆，接收到使用者請求時僅進行合法性驗證，驗證完成後直接告知成功，後續業務邏輯進入非同步佇列進行處理，減少了使用者的等待時間，也極大降低了峰值雪崩的概率。

耗時最長的入賬操作，直接跳過，非同步處理

另外一方面是採取過載保護措施：

微信紅包的過載保護在客戶端已提前預埋了策略，在連線失敗或超時情況下會有相應提示，減少使用者重複請求次數。接入層面也會進行自我保護，針對頻繁發出請求的客戶端限制響應速度，並對系統負載劃分出若干等級，達到不同閾值時引導客戶端使用不同限速速率；在異常情況出現時，採取減少紅包數，非同步限流降低拆/分享紅包的速率等措施減輕伺服器端壓力；與此同時，微信紅包還有全程壓測流程，對整個業務連結進行自動提前評估，防止過載 。

這畫面你可能沒見過，它其實早已在手機待命

在有損服務思想的重重保護下，第一波的搖紅包體驗活動中，微信紅包幾乎滿分通過考驗，其中過載保護的作用相當明顯，在客戶端、接入層層減壓、過濾，最終僅把十萬級壓力傳遞到後臺。

• 柔性可用-細化場景把握核心需求。

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

柔性服務更具有產品的思維性質，意義在於深刻理解產品每一個場景的核心價值，把握使用者在每一個場景中的核心需求，設計不同層次的滿足核心訴求的辦法，對柔性服務在微信紅包中的實踐，紅包團隊也有相應的措施，主要可以分為幾大類。

1、系統容災：面對大規模的請求量，系統容災必不可少，容災一般可分為邏輯層容災和資料層容災，這次微信後臺開發團隊在容災佈置中採用30%切換的邏輯層方案，即核心服務都能做到最多1/3伺服器出問題的情況下自動容災切換以保證服務質量，提高預警級別換取系統的可用性。

2、資源隔離：顧名思義就是把資源進行隔離減少服務支路間的影響，從邏輯入手，在資源邏輯中，當A服務同時分派任務給BC服務時，設定單個最大分配上限值，避免任意一個支路出問題影響整個服務鏈條，這樣即使部分服務出現問題也不會影響到整個服務的崩塌。

3、快速拒絕：當服務過載時儘早拒絕請求，由服務呼叫方換機重試避免單一伺服器重試過載，快速拒絕和有損服務中的及早拒絕是一個概念的方法，從過程的源頭將問題解決，成本越低，影響越小，前端保護後端的方式來解決問題。

4、支付分組：從支付環節入手，將所有紅包分為50個組，放在50個單獨的set上互不影響，單組set出問題最多隻影響1/50使用者，保證多數人服務不受干擾。分組set化也是柔性可用的一個重要技術手段，這一思維非常類似於現實生活中的集裝箱思維——通過標準化，規模化的箱體設計，應對複雜多樣的貨物，使每個流通環節既獨立又不失靈活。

5、流量預載入：從客戶端入手，將語音圖片等極消耗流量的資源提前讓客戶端自動下載預置好，提前將流量洪峰疏導，並在活動當天CDN將準備數百G頻寬應對，這塊也與過載保護中的快慢分離是相通的，將耗流量的服務提前載入避免高峰期間的衝突。

• 大系統小做-保證程序的功能單一。

大系統小做應該來說，是一種意識，他的核心思想是將功能複雜較大的系統，化大為小，減少模組耦合，降低關聯性，用多個獨立的模組來實現整體系統的功能，大系統小做採用的是化繁為簡，分而治之，便於開發和迅速實現。

微信紅包如此龐大的後臺系統，模組也相當之多，而這次的模組微信開發後臺團隊採用了系統高度模組化的方式，分成一個個高度自制的小系統，形成高內聚低耦合的格局，每個模組之間不會過分依賴對方，這樣的好處是不會因為任何一個模組而影響全部服務，避免牽一髮動全身的風險，實現真正的灰度服務。

海量服務能力決定成敗

從2014的滴滴打車，到2015的微信紅包，騰訊用一個個案例，去證明自身在海量服務方面的實力。事實上，真正支撐起微信紅包順暢運營的幕後英雄，正是騰訊內部一個叫做“海量之道2.0”的技術體系。有損服務，柔性服務，大系統小做三大手段也是脫胎於此體系中。移動網際網路大戰硝煙味愈濃，BAT都在為爭奪支付入口使出渾身解數，在業務從起步到小跑再到騰飛的過程中，巨頭背後的海量服務能力將對其最終成敗有著來越發深遠的影響。