1. 程式人生 > >揭祕微信紅包:架構、搶紅包演算法、高併發和降級方案

揭祕微信紅包:架構、搶紅包演算法、高併發和降級方案

編者按

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

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

微信紅包從15年春晚搖一搖之後,2015年上半年業務量一度呈指數級增長。為了應對16年春節可預知的紅包海量業務,紅包系統在架構上進行了一系列調整和優化。下面介紹最主要的一些思路。

架構

微信使用者在國內有深圳、上海兩個接入點,習慣性稱之為南、北(即深圳為南,上海為北)。使用者請求接入後,不同業務根據業務特性選擇部署方式。微信紅包在資訊流上可以分為訂單緯度與使用者緯度。其中訂單是貫穿紅包發、搶、拆、詳情列表等業務的關鍵資訊,屬於交易類資訊;而使用者緯度指的是紅包使用者的收紅包列表、發紅包列表,屬於展示類資訊。紅包系統在架構上,有以下幾個方面:

南北分佈

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年春節的實踐檢驗,平穩地度過了除夕業務高峰,保障了紅包使用者的體驗。