編者按
與傳統意義上的紅包相比，近兩年火起來的“紅包”，似乎纔是如今春節的一大重頭戲。歷經上千年時代傳承與變遷，春節發紅包早已成爲歷史沉澱的文化習俗，融入了民族的血脈。按照各家公佈的數據，除夕全天微信用戶紅包總髮送量達到80.8億個，紅包峯值收發量爲40.9萬個/秒。春晚直播期間討論春晚的微博達到5191萬條，網友互動量達到1.15億，網友搶微博紅包的總次數超過8億次。
爲此，InfoQ策劃了“春節紅包”系列文章，以期爲讀者剖析各大平臺的紅包活動背後的技術細節。本文爲微信篇。
微信紅包在經過15年春晚搖一搖之後，2015年上半年業務量一度呈指數級增長。尤其是微信紅包活躍用戶數的大量增長，使得2016除夕跨年紅包成爲極大挑戰。爲了應對16年春節可預知的紅包海量業務，紅包系統在架構上進行了一系列調整和優化。主要包括異地架構、cache系統優化、拆紅包併發策略優化、存儲優化一系列措施，爲迎接2016春節紅包挑戰做好準備。 下面介紹最主要的一些思路。
架構
微信用戶在國內有深圳、上海兩個接入點，習慣性稱之爲南、北（即深圳爲南，上海爲北）。用戶請求接入後，不同業務根據業務特性選擇部署方式。微信紅包在信息流上可以分爲訂單緯度與用戶緯度。其中訂單是貫穿紅包發、搶、拆、詳情列表等業務的關鍵信息，屬於交易類信息；而用戶緯度指的是紅包用戶的收紅包列表、發紅包列表，屬於展示類信息。紅包系統在架構上，有以下幾個方面：
南北分佈
1、訂單層南北獨立體系，數據不同步
用戶就近接入，請求發紅包時分配訂單南北，並在單號打上南北標識。搶紅包、拆紅包、查紅包詳情列表時，接入層根據紅包單號上的南北標識將流量分別引到南北系統閉環。根據發紅包用戶和搶紅包用戶的所屬地不同，有以下四種情況：
1) 深圳用戶發紅包，深圳用戶搶
訂單落在深圳，深圳用戶搶紅包時不需要跨城，在深圳完成閉環。
2) 深圳用戶發紅包，上海用戶搶
訂單落在深圳，上海用戶搶紅包，在上海接入後通過專線跨城到深圳，最後在深圳閉環完成搶紅包。
3) 上海用戶發紅包，上海用戶搶
訂單落在上海，上海用戶搶紅包時不需要跨城，在上海完成閉環。
4) 上海用戶發紅包，深圳用戶搶
訂單落在上海，深圳用戶搶紅包，從深圳接入後通過專線跨城到上海，最後在上海閉環完成搶紅包。
系統這樣設計，好處是南北系統分攤流量，降低系統風險。
2、用戶數據寫多讀少，全量存深圳，異步隊列寫入，查時一邊跨城
用戶數據的查詢入口，在微信錢包中，隱藏的很深。這決定了用戶數據的訪問量不會太大，而且也被視爲可旁路的非關鍵信息，實時性要求不高。因此，只需要在發紅包、拆紅包時，從訂單緯度拆分出用戶數據寫入請求，由MQ異步寫入深圳。後臺將訂單與用戶進行定時對賬保證數據完整性即可。
3、支持南北流量靈活調控
紅包系統南北分佈後，訂單落地到深圳還是上海，是可以靈活分配的，只需要在接入層上做邏輯。例如，可以在接入層中，實現讓所有紅包請求，都落地到深圳（無論用戶從上海接入，還是深圳接入），這樣上海的紅包業務系統將不會有請求量。提升了紅包系統的容災能力。同時，實現了接入層上的後臺管理系統，實現了秒級容量調控能力。可根據南北請求量的實時監控，做出對應的調配。
4、DB故障時流量轉移能力
基於南北流量的調控能力，當發現DB故障時，可將紅包業務流量調到另外一邊，實現DB故障的容災。
預訂單
支付前訂單落cache，同時利用cache的原子incr操作順序生成紅包訂單號。優點是cache的輕量操作，以及減少DB廢單。在用戶請求發紅包與真正支付之間，存在一定的轉化率，部分用戶請求發紅包後，並不會真正去付款。
拆紅包入賬異步化
信息流與資金流分離。拆紅包時，DB中記下拆紅包憑證，然後異步隊列請求入賬。入賬失敗通過補償隊列補償，最終通過紅包憑證與用戶賬戶入賬流水對賬，保證最終一致性。
這個架構設計，理論基礎是快慢分離。紅包的入賬是一個分佈事務，屬於慢接口。而拆紅包憑證落地則速度快。實際應用場景中，用戶搶完紅包，只關心詳情列表中誰是“最佳手氣”，很少關心搶到的零是否已經到賬。因爲只需要展示用戶的拆紅包憑證即可。
發拆落地，其他操作雙層cache
1、Cache住所有查詢，兩層cache
除了使用ckv做全量緩存，還在數據訪問層dao中增加本機內存cache做二級緩存，cache住所有讀請求。
查詢失敗或者查詢不存在時，降級內存cache；內存cache查詢失敗或記錄不存在時降級DB。
DB本身不做讀寫分離。
2、DB寫同步cache，容忍少量不一致
DB寫操作完成後，dao中同步內存cache，業務服務層同步ckv，失敗由異步隊列補償，定時的ckv與DB備機對賬，保證最終數據一致。
高併發
微信紅包的併發挑戰，主要在於微信大羣，多人同時搶同一個紅包。這種情況，存在競爭MySQL行鎖。爲了控制這種併發，團隊做了以下一些事情：
1、請求按紅包訂單路由，邏輯塊垂直sticky，事務隔離
按紅包訂單劃分邏輯單元，單元內業務閉環。服務rpc調用時，使用紅包訂單號的hash值爲key尋找下一跳地址。對同一個紅包的所有拆請求、查詢請求，都路由到同一臺邏輯機器、同一臺DB中處理。
2、Dao搭建本機Memcache內存cache，控制同一紅包併發個數
在DB的接入機dao中，搭建本機內存cache。以紅包訂單號爲key，對同一個紅包的拆請求做原子計數，控制同一時刻能進DB中拆紅包的併發請求數。
這個策略的實施，依賴於請求路由按紅包訂單hash值走，確保同一紅包的所有請求路由到同一邏輯層機器。
3、多層級併發量控制
1) 發紅包控制
發紅包是業務流程的入口，控制了這裏的併發量，代表着控制了紅包業務整體的併發量。在發紅包的業務鏈路裏，做了多層的流量控制，確保產生的有效紅包量級在可控範圍。
2) 搶紅包控制
微信紅包領取時分爲兩個步驟，搶和拆。搶紅包這個動作本身就有控制拆併發的作用。因爲搶紅包時，只需要查cache中的數據，不需要請求DB。對於紅包已經領完、用戶已經領過、紅包已經過期等流量可以直接攔截。而對於有資格進入拆紅包的請求量，也做流量控制。通過這些處理，最後可進入拆環節的流量大大減少，並且都是有效請求。
3) 拆時內存cache控制
針對同一個紅包併發拆的控制，上文已經介紹。
4、DB簡化和拆分
DB的併發能力，有很多影響因素。紅包系統結合紅包使用情境，進行了一些優化。比較有借鑑意義的，主要有以下兩點：
1) 訂單表只存關鍵字段，其他字段只在cache中存儲，可柔性。
紅包詳情的展示中，除了訂單關鍵信息（用戶、單號、金額、時間、狀態）外，還有用戶頭像、暱稱、祝福語等字段。這些字段對交易來說不是關鍵信息，卻佔據大量的存儲空間。
將這些非關鍵信息拆出來，只存在cache，用戶查詢展示，而訂單中不落地。這樣可以維持訂單的輕量高效，同時cache不命中時，又可從實時接口中查詢補償，達到優化訂單DB容量的效果。
2) DB雙重緯度分庫表，冷熱分離
使用訂單hash、訂單日期，兩個緯度分庫表，也即db_xxx.t_x_dd這樣的格式。其中，x表示訂單hash值，dd表示01-31循環日。訂單hash緯度，是爲了將訂單打散到不同的DB服務器中，均衡壓力。訂單日期循環日緯度，是爲了避免單表數據無限擴張，使每天都是一張空表。
另外，紅包的訂單訪問熱度，是非常典型的冷熱型。熱數據集中在一兩天內，且隨時間急劇消減。線上熱數據庫只需要存幾天的數據，其他數據可以定時移到成本低的冷數據庫中。循環日表也使得歷史數據的遷移變得方便。
紅包算法
首先，如果紅包只有一個，本輪直接使用全部金額，確保紅包發完。
然後，計算出本輪紅包最少要領取多少，才能保證紅包領完，即本輪下水位；輪最多領取多少，才能保證每個人都領到，即本輪上水位。主要方式如下：
計算本輪紅包金額下水位：假設本輪領到最小值1分，那接下來每次都領到200元紅包能領完，那下水位爲1分；如果不能領完，那按接下來每次都領200元，剩下的本輪應全部領走，是本輪的下水位。
計算本輪紅包上水位：假設本輪領200元，剩下的錢還足夠接下來每輪領1分錢，那本輪上水位爲200元；如果已經不夠領，那按接下來每輪領1分，計算本輪的上水位。
爲了使紅包金額不要太懸殊，使用紅包均值調整上水位。如果上水位金額大於兩倍紅包均值，那麼使用兩倍紅包均值作爲上水位。換句話說，每一輪搶到的紅包金額，最高爲兩倍剩下紅包的均值。
最後，獲取隨機數並用上水位取餘，如果結果比下水位還小，則直接使用下水位，否則使用隨機金額爲本輪拆到金額。
柔性降級方案
系統到處存在發生異常的可能，需要對所有的環節做好應對的預案。下面列舉微信紅包對系統異常的主要降級考慮。
1、 下單cache故障降級DB
下單cache有兩個作用，生成紅包訂單與訂單緩存。緩存故障情況下，降級爲直接落地DB，並使用id生成器獨立生成訂單號。
2、 搶時cache故障降級DB
搶紅包時，查詢cache，攔截紅包已經搶完、用戶已經搶過、紅包已經過期等無效請求。當cache故障時，降級DB查詢，同時打開DB限流保護開關，防止DB壓力過大導致服務不可用。
另外，cache故障降級DB時，DB不存儲用戶頭像、用戶暱稱等（上文提到的優化），此時一併降級爲實時接口查詢。查詢失敗，繼續降級爲展示默認頭像與暱稱。
3、 拆時資金入賬多級柔性
拆紅包時，DB記錄拆紅包單據，然後執行資金轉賬。單據需要實時落地，而資金轉賬，這裏做了多個層級的柔性降級方案：
大額紅包實時轉賬，小額紅包入隊列異步轉賬 所有紅包進隊列異步轉賬 實時流程不執行轉賬，事後憑單據批量入賬。
總之，單據落地後，真實入賬可實時、可異步，最終保證一致即可。
4、 用戶列表降級
用戶列表數據在微信紅包系統中，屬於非關鍵路徑信息，屬於可被降級部分。
首先，寫入時通過MQ異步寫，通過定時對賬保證一致性。
其次，cache中只緩存兩屏，用戶查詢超過兩屏則查用戶列表DB。在系統壓力大的情況下，可以限制用戶只查兩屏。
調整後的系統經過了16年春節的實踐檢驗，平穩地度過了除夕業務高峯，保障了紅包用戶的體驗。
作者介紹
方樂明，2011年畢業於華南理工大學通信與信息系統專業，畢業後就職於財付通科技有限公司。微信支付團隊組建後，主要負責微信紅包、微信轉賬、AA收款等支付應用產品的後臺架構。
原文：http://www.infoq.com
http://cxy.liuzhihengseo.com/522.html