2017年1月28日糕簿，正月初一怀挠，微信公布了用戶在除夕當天收發(fā)微信紅包的數(shù)量——142億個，而其收發(fā)峰值也已達到76萬每秒撩匕。百億級別的紅包鹰晨，如何保障并發(fā)性能與資金安全？這給微信帶來了超級挑戰(zhàn)止毕。面對挑戰(zhàn)模蜡，微信紅包在分析了業(yè)界“秒殺”系統(tǒng)解決方案的基礎(chǔ)上，采用了SET化扁凛、請求排隊串行化忍疾、雙維度分庫表等設(shè)計，形成了獨特的高并發(fā)谨朝、資金安全系統(tǒng)解決方案卤妒。實踐證明，該方案表現(xiàn)穩(wěn)定字币，且實現(xiàn)了除夕夜系統(tǒng)零故障運行则披。概要：

一、業(yè)務(wù)特點：海量的并發(fā)要求洗出；嚴格的安全級別

二士复、技術(shù)難點：并發(fā)請求搶鎖；事務(wù)級操作量級大翩活；事務(wù)性要求嚴格

三阱洪、解決高并發(fā)問題通常使用的方案：

1.使用內(nèi)存操作替代實時的DB事務(wù)操作（優(yōu)點：內(nèi)存操作替代磁盤操作便贵，提高了并發(fā)性能。）

2使用樂觀鎖替代悲觀鎖冗荸。應(yīng)用于微信紅包系統(tǒng)嫉沽，則會存在下面三個問題：滾并返回失敗俏竞；并發(fā)大失敗，小成功堂竟。DB壓力大魂毁。

四、微信紅包系統(tǒng)的高并發(fā)解決方案：

1.系統(tǒng)垂直SET化出嘹，分而治之席楚。

2.邏輯Server層將請求排隊，解決DB并發(fā)問題税稼。

3.雙維度庫表設(shè)計烦秩，保障系統(tǒng)性能穩(wěn)定

一、微信紅包的兩大業(yè)務(wù)特點

類似“秒殺”活動郎仆，群里發(fā)一個紅包=“秒殺”商品上架只祠；搶紅包的動作=“秒殺”的查詢庫存；拆紅包=“秒殺”

首先扰肌，微信紅包業(yè)務(wù)比普通商品“秒殺”有更海量的并發(fā)要求抛寝。

同一時間有10萬個群里的用戶同時在發(fā)紅包，那就相當于同一時間有10萬個“秒殺”活動發(fā)布出去曙旭。10萬個微信群里的用戶同時搶紅包盗舰，將產(chǎn)生海量的并發(fā)請求。

其次桂躏，微信紅包業(yè)務(wù)要求更嚴格的安全級別钻趋。

微信紅包是微信支付的一個商戶，提供資金流轉(zhuǎn)服務(wù)剂习。

用戶發(fā)紅包=購買一筆“錢”（在微信紅包這個商戶上）蛮位，并且收貨地址是微信群。當用戶支付成功后鳞绕，紅包“發(fā)貨”到微信群里土至，群里的用戶拆開紅包后，微信紅包提供了將“錢”轉(zhuǎn)入折紅包用戶微信零錢的服務(wù)猾昆。

資金交易業(yè)務(wù)比普通商品“秒殺”活動有更高的安全級別要求陶因。普通的商品“秒殺”商品由商戶提供，庫存是商戶預(yù)設(shè)的垂蜗，“秒殺”時可以允許存在“超賣”楷扬、“少賣”的情況解幽。但是對于微信紅包，100元不可以被拆出101元烘苹；領(lǐng)取99元時躲株，剩下的1元在24小時過期后要精確地退還給發(fā)紅包用戶，不能多也不能少镣衡。

二霜定、 微信紅包系統(tǒng)的技術(shù)難點

在介紹微信紅包系統(tǒng)的技術(shù)難點之前，先介紹下簡單的廊鸥、典型的商品“秒殺”系統(tǒng)的架構(gòu)設(shè)計望浩，如下圖所示。

該系統(tǒng)由接入層惰说、邏輯服務(wù)層磨德、存儲層與緩存構(gòu)成。Proxy處理請求接入吆视，Server承載主要的業(yè)務(wù)邏輯典挑，Cache用于緩存庫存數(shù)量、DB則用于數(shù)據(jù)持久化啦吧。

一個“秒殺”活動您觉，對應(yīng)DB中的一條庫存記錄。當用戶進行商品“秒殺”時授滓，系統(tǒng)的主要邏輯在于DB中庫存的操作上顾犹。一般來說，對DB的操作流程有以下三步：

a. 鎖庫存

b. 插入“秒殺”記錄

c. 更新庫存

a.鎖庫存是為了避免并發(fā)請求時出現(xiàn)“超賣”情況褒墨。同時要求這三步操作需要在一個事務(wù)中完成(難點:并發(fā)請求搶鎖)炫刷。

第一個事務(wù)完成提交之前這個鎖一直被第一個請求占用，后面的所有請求需要排隊等待郁妈。同時參與“秒殺”的用戶越多浑玛，并發(fā)進DB的請求越多，請求排隊越嚴重噩咪。

紅包系統(tǒng)的設(shè)計上顾彰，除了并發(fā)請求搶鎖之外，還有以下兩個突出難點：

首先胃碾，事務(wù)級操作量級大涨享。上文介紹微信紅包業(yè)務(wù)特點時提到，普遍情況下同時會有數(shù)以萬計的微信群在發(fā)紅包仆百。這個業(yè)務(wù)特點映射到微信紅包系統(tǒng)設(shè)計上厕隧，就是有數(shù)以萬計的“并發(fā)請求搶鎖”同時在進行。這使得DB的壓力比普通單個商品“庫存”被鎖要大很多倍。

其次吁讨，事務(wù)性要求嚴格髓迎。微信紅包系統(tǒng)本質(zhì)上是一個資金交易系統(tǒng)，相比普通商品“秒殺”系統(tǒng)有更高的事務(wù)級別要求建丧。

三排龄、解決高并發(fā)問題通常使用的方案

普通商品“秒殺”活動系統(tǒng)，解決高并發(fā)問題的方案翎朱，大體有以下幾種：

方案一橄维，使用內(nèi)存操作替代實時的DB事務(wù)操作。

如圖2所示拴曲，將“實時扣庫存”的行為上移到內(nèi)存Cache中操作争舞，內(nèi)存Cache操作成功直接給Server返回成功，然后異步落DB持久化疗韵。

優(yōu)點：提高了并發(fā)性能。

缺點：在內(nèi)存操作成功但DB持久化失敗侄非，或者內(nèi)存Cache故障的情況下蕉汪，DB持久化會丟數(shù)據(jù)，不適合微信紅包這種資金交易系統(tǒng)逞怨。

方案二者疤，使用樂觀鎖替代悲觀鎖。

商品“秒殺”系統(tǒng)中叠赦，樂觀鎖的具體應(yīng)用方法驹马，是在DB的“庫存”記錄中維護一個版本號。在更新“庫存”的操作進行前除秀，先去DB獲取當前版本號糯累。在更新庫存的事務(wù)提交時，檢查該版本號是否已被其他事務(wù)修改册踩。如果版本沒被修改泳姐，則提交事務(wù)，且版本號加1暂吉；如果版本號已經(jīng)被其他事務(wù)修改胖秒，則回滾事務(wù)，并給上層報錯慕的。

這個方案解決了“并發(fā)請求搶鎖”的問題阎肝，可以提高DB的并發(fā)處理能力。

應(yīng)用于微信紅包系統(tǒng)肮街，則會存在下面三個問題：

1.在并發(fā)搶到相同版本號的拆紅包請求中风题，只有一個能拆紅包成功，其他的請求將事務(wù)回滾并返回失敗，給用戶報錯俯邓，用戶體驗完全不可接受骡楼。

2.將會導致第一時間同時拆紅包的用戶有一部分直接返回失敗，反而那些“手慢”的用戶稽鞭，有可能因為并發(fā)減小后拆紅包成功鸟整，這會帶來用戶體驗上的負面影響。

3.會帶來大數(shù)量的無效更新請求朦蕴、事務(wù)回滾篮条，給DB造成不必要的額外壓力。

四吩抓、微信紅包系統(tǒng)的高并發(fā)解決方案

1.系統(tǒng)垂直SET化涉茧，分而治之。

微信紅包用戶發(fā)一個紅包時疹娶，微信紅包系統(tǒng)生成一個ID作為這個紅包的唯一標識伴栓。接下來這個紅包的所有發(fā)紅包、搶紅包雨饺、拆紅包钳垮、查詢紅包詳情等操作，都根據(jù)這個ID關(guān)聯(lián)额港。

紅包系統(tǒng)根據(jù)這個紅包ID饺窿，按一定的規(guī)則（如按ID尾號取模等），垂直上下切分移斩。切分后肚医，一個垂直鏈條上的邏輯Server服務(wù)器、DB統(tǒng)稱為一個SET向瓷。

各個SET之間相互獨立肠套，互相解耦。并且同一個紅包ID的所有請求猖任，包括發(fā)紅包糠排、搶紅包、拆紅包超升、查詳情詳情等入宦，垂直stick到同一個SET內(nèi)處理，高度內(nèi)聚室琢。通過這樣的方式乾闰，系統(tǒng)將所有紅包請求這個巨大的洪流分散為多股小流，互不影響盈滴，分而治之涯肩，如下圖所示轿钠。

這個方案解決了同時存在海量事務(wù)級操作的問題，將海量化為小量病苗。

2.邏輯Server層將請求排隊疗垛，解決DB并發(fā)問題。

紅包系統(tǒng)是資金交易系統(tǒng)硫朦，DB操作的事務(wù)性無法避免贷腕，所以會存在“并發(fā)搶鎖”問題。但是如果到達DB的事務(wù)操作（也即拆紅包行為）不是并發(fā)的咬展，而是串行的泽裳，就不會存在“并發(fā)搶鎖”的問題了。

按這個思路破婆，為了使拆紅包的事務(wù)操作串行地進入DB涮总，只需要將請求在Server層以FIFO（先進先出）的方式排隊，就可以達到這個效果祷舀。從而問題就集中到Server的FIFO隊列設(shè)計上瀑梗。

微信紅包系統(tǒng)設(shè)計了分布式的、輕巧的裳扯、靈活的FIFO隊列方案抛丽。其具體實現(xiàn)如下：

首先，將同一個紅包ID的所有請求stick到同一臺Server嚎朽。

上面SET化方案已經(jīng)介紹铺纽，同個紅包ID的所有請求柬帕，按紅包ID stick到同個SET中哟忍。不過在同個SET中，會存在多臺Server服務(wù)器同時連接同一臺DB（基于容災(zāi)陷寝、性能考慮锅很，需要多臺Server互備、均衡壓力）凤跑。

為了使同一個紅包ID的所有請求爆安，stick到同一臺Server服務(wù)器上，在SET化的設(shè)計之外仔引，微信紅包系統(tǒng)添加了一層基于紅包ID hash值的分流扔仓，如下圖所示。

其次咖耘，設(shè)計單機請求排隊方案翘簇。

將stick到同一臺Server上的所有請求在被接收進程接收后，按紅包ID進行排隊儿倒。然后串行地進入worker進程（執(zhí)行業(yè)務(wù)邏輯）進行處理版保，從而達到排隊的效果，如下圖所示。

最后彻犁，增加memcached控制并發(fā)叫胁。

為了防止Server中的請求隊列過載導致隊列被降級，從而所有請求擁進DB汞幢，系統(tǒng)增加了與Server服務(wù)器同機部署的memcached驼鹅，用于控制拆同一個紅包的請求并發(fā)數(shù)。

具體來說急鳄，利用memcached的CAS原子累增操作谤民，控制同時進入DB執(zhí)行拆紅包事務(wù)的請求數(shù)，超過預(yù)先設(shè)定數(shù)值則直接拒絕服務(wù)疾宏。用于DB負載升高時的降級體驗张足。

通過以上三個措施，系統(tǒng)有效地控制了DB的“并發(fā)搶鎖”情況坎藐。

3.雙維度庫表設(shè)計为牍，保障系統(tǒng)性能穩(wěn)定

紅包系統(tǒng)的分庫表規(guī)則，初期是根據(jù)紅包ID的hash值分為多庫多表岩馍。隨著紅包數(shù)據(jù)量逐漸增大碉咆，單表數(shù)據(jù)量也逐漸增加。而DB的性能與單表數(shù)據(jù)量有一定相關(guān)性蛀恩。當單表數(shù)據(jù)量達到一定程度時疫铜，DB性能會有大幅度下降，影響系統(tǒng)性能穩(wěn)定性双谆。采用冷熱分離壳咕，將歷史冷數(shù)據(jù)與當前熱數(shù)據(jù)分開存儲，可以解決這個問題顽馋。

系統(tǒng)在以紅包ID維度分庫表的基礎(chǔ)上谓厘，增加了以循環(huán)天分表的維度，形成了雙維度分庫表的特色寸谜。

具體來說竟稳，就是分庫表規(guī)則像db_xx.t_y_dd設(shè)計，其中熊痴，xx/y是紅包ID的hash值后三位他爸，dd的取值范圍在01~31，代表一個月天數(shù)最多31天果善。

通過這種雙維度分庫表方式诊笤，解決了DB單表數(shù)據(jù)量膨脹導致性能下降的問題，保障了系統(tǒng)性能的穩(wěn)定性岭埠。同時盏混，在熱冷分離的問題上蔚鸥，又使得數(shù)據(jù)搬遷變得簡單而優(yōu)雅。

綜上所述许赃，微信紅包系統(tǒng)在解決高并發(fā)問題上的設(shè)計止喷，主要采用了SET化分治、請求排隊混聊、雙維度分庫表等方案弹谁，使得單組DB的并發(fā)性能提升了8倍左右，取得了很好的效果句喜。

http://www.infoq.com/cn/articles/2017hongbao-weixin