系統(tǒng)實(shí)現(xiàn)方案設(shè)計(jì)

1、系統(tǒng)實(shí)現(xiàn)方案設(shè)計(jì)設(shè)計(jì)要確定設(shè)計(jì)方案，首先要清楚設(shè)計(jì)的目的和所要達(dá) 到的效果。下面本人給大家?guī)硐到y(tǒng)實(shí)現(xiàn)方案設(shè)計(jì)，歡迎大 家閱讀。XX年1月28日，正月初一，微信公布了用戶在除夕當(dāng) 天收發(fā)微信紅包的數(shù)量 142 億個(gè)，而其收發(fā)峰值也已達(dá) 到 76 萬每秒。百億級別的紅包，如何保障并發(fā)性能與資金 安全？這給微信帶來了超級挑戰(zhàn)。面對挑戰(zhàn)，微信紅包在分 析了業(yè)界“秒殺”系統(tǒng)解決方案的基礎(chǔ)上，采用了SET 化、請求排隊(duì)串行化、雙維度分庫表等設(shè)計(jì)，形成了獨(dú)特的高并 發(fā)、資金安全系統(tǒng)解決方案。實(shí)踐證明，該方案表現(xiàn)穩(wěn)定， 且實(shí)現(xiàn)了除夕夜系統(tǒng)零故障運(yùn)行。本文將為讀者介紹百億級別紅包背后的系統(tǒng)高并發(fā)設(shè) 計(jì)方案，包

2、括微信紅包的兩大業(yè)務(wù)特點(diǎn)、微信紅包系統(tǒng)的技 術(shù)難點(diǎn)、解決高并發(fā)問題通常使用的方案，以及微信紅包系 統(tǒng)的高并發(fā)解決方案。微信紅包業(yè)務(wù)形態(tài)上很類似網(wǎng)上的普通商品“秒殺”活 動。用戶在微信群里發(fā)一個(gè)紅包， 等同于是普通商品 “秒殺” 活動的商品上架；微信群里的所有用戶搶紅包的動作，等同 于“秒殺”活動中的查詢庫存；用戶搶到紅包后拆紅包的動 作，則對應(yīng)“秒殺”活動中用戶的“秒殺”動作。不過除了上面的相同點(diǎn)之外，微信紅包在業(yè)務(wù)形態(tài)上與普通商品“秒殺”活動相比，還具備自身的特點(diǎn)： 首先，微信紅包業(yè)務(wù)比普通商品“秒殺”有更海量的并 發(fā)要求。微信紅包用戶在微信群里發(fā)一個(gè)紅包，等同于在網(wǎng)上發(fā) 布一次商品“秒殺”

3、活動。假設(shè)同一時(shí)間有 10 萬個(gè)群里的 用戶同時(shí)在發(fā)紅包， 那就相當(dāng)于同一時(shí)間有 10 萬個(gè)“秒殺” 活動發(fā)布出去。 10 萬個(gè)微信群里的用戶同時(shí)搶紅包， 將產(chǎn)生 海量的并發(fā)請求。其次，微信紅包業(yè)務(wù)要求更嚴(yán)格的安全級別。 微信紅包業(yè)務(wù)本質(zhì)上是資金交易。微信紅包是微信支付 的一個(gè)商戶，提供資金流轉(zhuǎn)服務(wù)。用戶發(fā)紅包時(shí)，相當(dāng)于在微信紅包這個(gè)商戶上使用微信 支付購買一筆“錢” ，并且收貨地址是微信群。當(dāng)用戶支付 成功后， 紅包“發(fā)貨” 到微信群里， 群里的用戶拆開紅包后， 微信紅包提供了將“錢”轉(zhuǎn)入折紅包用戶微信零錢的服務(wù)。資金交易業(yè)務(wù)比普通商品“秒殺”活動有更高的安全級 別要求。普通的商品“秒殺”商

4、品由商戶提供，庫存是商戶 預(yù)設(shè)的，“秒殺”時(shí)可以允許存在“超賣” 、“少賣”的情況。 但是對于微信紅包，用戶發(fā) 100 元的紅包絕對不可以被拆出 101 元；用戶發(fā) 100 元只被領(lǐng)取 99 元時(shí)，剩下的 1 元在 24 小時(shí)過期后要精確地退還給發(fā)紅包用戶，不能多也不能少。以上是微信紅包業(yè)務(wù)模型上的兩大特點(diǎn)。 在介紹微信紅包系統(tǒng)的技術(shù)難點(diǎn)之前，先介紹下簡單的、 典型的商品“秒殺”系統(tǒng)的架構(gòu)設(shè)計(jì)，如下圖所示。該系統(tǒng)由接入層、邏輯服務(wù)層、存儲層與緩存構(gòu)成。Proxy 處理請求接入， Server 承載主要的業(yè)務(wù)邏輯， Cache 用于緩存庫存數(shù)量、DB則用于數(shù)據(jù)持久化。一個(gè)“秒殺”活動，對應(yīng) DB

5、 中的一條庫存記錄。當(dāng)用 戶進(jìn)行商品“秒殺”時(shí)，系統(tǒng)的主要邏輯在于 DB 中庫存的 操作上。一般來說，對 DB的操作流程有以下三步： 插入“秒殺”記錄 其中，鎖庫存是為了避免并發(fā)請求時(shí)出現(xiàn) “超賣”情況。 同時(shí)要求這三步操作需要在一個(gè)事務(wù)中完成?！懊霘ⅰ毕到y(tǒng)的設(shè)計(jì)難點(diǎn)就在這個(gè)事務(wù)操作上。商品庫 存在 DB 中記為一行，大量用戶同時(shí)“秒殺”同一商品時(shí)， 第一個(gè)到達(dá) DB 的請求鎖住了這行庫存記錄。在第一個(gè)事務(wù) 完成提交之前這個(gè)鎖一直被第一個(gè)請求占用，后面的所有請 求需要排隊(duì)等待。同時(shí)參與“秒殺”的用戶越多，并發(fā)進(jìn) DB 的請求越多，請求排隊(duì)越嚴(yán)重。因此，并發(fā)請求搶鎖，是典 型的商品“秒殺”系統(tǒng)的

6、設(shè)計(jì)難點(diǎn)。微信紅包業(yè)務(wù)相比普通商品“秒殺”活動，具有海量并 發(fā)、高安全級別要求的特點(diǎn)。在微信紅包系統(tǒng)的設(shè)計(jì)上，除 了并發(fā)請求搶鎖之外，還有以下兩個(gè)突出難點(diǎn)： 首先，事務(wù)級操作量級大。上文介紹微信紅包業(yè)務(wù)特點(diǎn) 時(shí)提到，普遍情況下同時(shí)會有數(shù)以萬計(jì)的微信群在發(fā)紅包。 這個(gè)業(yè)務(wù)特點(diǎn)映射到微信紅包系統(tǒng)設(shè)計(jì)上，就是有數(shù)以萬計(jì) 的“并發(fā)請求搶鎖”同時(shí)在進(jìn)行。這使得 DB 的壓力比普通 單個(gè)商品“庫存”被鎖要大很多倍。其次，事務(wù)性要求嚴(yán)格。微信紅包系統(tǒng)本質(zhì)上是一個(gè)資 金交易系統(tǒng)，相比普通商品“秒殺”系統(tǒng)有更高的事務(wù)級別 要求。普通商品“秒殺”活動系統(tǒng)，解決高并發(fā)問題的方案， 大體有以下幾種：方案一，使用內(nèi)存操

7、作替代實(shí)時(shí)的DB事務(wù)操作。如圖 2 所示，將“實(shí)時(shí)扣庫存” 的行為上移到內(nèi)存 Cache 中操作，內(nèi)存 Cache 操作成功直接給 Server 返回成功，然 后異步落DB持久化。這個(gè)方案的優(yōu)點(diǎn)是用內(nèi)存操作替代磁盤操作，提高了并 發(fā)性能。但是缺點(diǎn)也很明顯，在內(nèi)存操作成功但 DB持久化失敗， 或者內(nèi)存Cache故障的情況下，DB持久化會丟數(shù)據(jù)，不適合 微信紅包這種資金交易系統(tǒng)。方案二，使用樂觀鎖替代悲觀鎖所謂悲觀鎖，是關(guān)系數(shù)據(jù)庫管理系統(tǒng)里的一種并發(fā)控制 的方法。它可以阻止一個(gè)事務(wù)以影響其他用戶的方式來修改 數(shù)據(jù)。如果一個(gè)事務(wù)執(zhí)行的操作對某行數(shù)據(jù)應(yīng)用了鎖，那只 有當(dāng)這個(gè)事務(wù)把鎖釋放，其他事務(wù)才能夠

8、執(zhí)行與該鎖沖突的 操作。對應(yīng)于上文分析中的“并發(fā)請求搶鎖”行為。所謂樂觀鎖，它假設(shè)多用戶并發(fā)的事務(wù)在處理時(shí)不會彼 此互相影響，各事務(wù)能夠在不產(chǎn)生鎖的情況下處理各自影響 的那部分?jǐn)?shù)據(jù)。在提交數(shù)據(jù)更新之前，每個(gè)事務(wù)會先檢查在 該事務(wù)讀取數(shù)據(jù)后，有沒有其他事務(wù)又修改了該數(shù)據(jù)。如果 其他事務(wù)有更新的話，正在提交的事務(wù)會進(jìn)行回滾。DBDB商品“秒殺”系統(tǒng)中，樂觀鎖的具體應(yīng)用方法，是在 的“庫存”記錄中維護(hù)一個(gè)版本號。在更新“庫存”的操作 進(jìn)行前，先去 DB 獲取當(dāng)前版本號。在更新庫存的事務(wù)提交 時(shí)，檢查該版本號是否已被其他事務(wù)修改。如果版本沒被修 改，則提交事務(wù)，且版本號加 1；如果版本號已經(jīng)被其他事

9、務(wù)修改，則回滾事務(wù)，并給上層報(bào)錯。這個(gè)方案解決了“并發(fā)請求搶鎖”的問題，可以提高 的并發(fā)處理能力。但是如果應(yīng)用于微信紅包系統(tǒng)，則會存在下面三個(gè)問題： 如果拆紅包采用樂觀鎖，那么在并發(fā)搶到相同版本號的 拆紅包請求中，只有一個(gè)能拆紅包成功，其他的請求將事務(wù) 回滾并返回失敗，給用戶報(bào)錯，用戶體驗(yàn)完全不可接受。如果采用樂觀鎖，將會導(dǎo)致第一時(shí)間同時(shí)拆紅包的用戶 有一部分直接返回失敗，反而那些“手慢”的用戶，有可能 因?yàn)椴l(fā)減小后拆紅包成功，這會帶來用戶體驗(yàn)上的負(fù)面影 響。如果采用樂觀鎖的方式，會帶來大數(shù)量的無效更新請求、 事務(wù)回滾，給DB造成不必要的額外壓力。基于以上原因，微信紅包系統(tǒng)不能采用樂觀鎖的方

10、式解 決并發(fā)搶鎖問題。微信紅包系統(tǒng)的高并發(fā)解決方案 綜合上面的分析，微信紅包系統(tǒng)針對相應(yīng)的技術(shù)難點(diǎn)， 采用了下面幾個(gè)方案，解決高并發(fā)問題。1.系統(tǒng)垂直SET化，分而治之。微信紅包用戶發(fā)一個(gè)紅包時(shí)， 微信紅包系統(tǒng)生成一個(gè) ID 作為這個(gè)紅包的唯一標(biāo)識。接下來這個(gè)紅包的所有發(fā)紅包、 搶紅包、拆紅包、查詢紅包詳情等操作，都根據(jù)這個(gè) ID 關(guān) 聯(lián)。紅包系統(tǒng)根據(jù)這個(gè)紅包 ID，按一定的規(guī)則，垂直上下切 分。切分后，一個(gè)垂直鏈條上的邏輯 Server服務(wù)器、DB統(tǒng) 稱為一個(gè) SET。各個(gè)SET之間相互獨(dú)立，互相解耦。并且同一個(gè)紅包ID 的所有請求， 包括發(fā)紅包、 搶紅包、 拆紅包、 查詳情詳情等， 垂直s

11、tick到同一個(gè)SET內(nèi)處理，高度內(nèi)聚。通過這樣的方式，系統(tǒng)將所有紅包請求這個(gè)巨大的洪流分散為多股小流， 互不影響，分而治之，如下圖所示這個(gè)方案解決了同時(shí)存在海量事務(wù)級操作的問題，將海 量化為小量。2.邏輯Server層將請求排隊(duì)，解決 DB并發(fā)問題。紅包系統(tǒng)是資金交易系統(tǒng)， DB 操作的事務(wù)性無法避免， 所以會存在“并發(fā)搶鎖”問題。但是如果到達(dá) DB 的事務(wù)操 作不是并發(fā)的，而是串行的，就不會存在“并發(fā)搶鎖”的問 題了。按這個(gè)思路，為了使拆紅包的事務(wù)操作串行地進(jìn)入DB，只需要將請求在 Server 層以 FIFO 的方式排隊(duì)，就可以達(dá)到 這個(gè)效果。從而問題就集中到 Server 的 FIFO

12、 隊(duì)列設(shè)計(jì)上。微信紅包系統(tǒng)設(shè)計(jì)了分布式的、輕巧的、靈活的 FIFO 隊(duì)列方案。其具體實(shí)現(xiàn)如下：首先，將同一個(gè)紅包 ID 的所有請求 stick 到同一臺 Server 。上面 SET 化方案已經(jīng)介紹，同個(gè)紅包ID 的所有請求，按紅包ID stick 到同個(gè)SET中。不過在同個(gè) SET中，會存 在多臺 Server 服務(wù)器同時(shí)連接同一臺 DB。為了使同一個(gè)紅包 ID 的所有請求， stick 到同一臺Server服務(wù)器上，在SET化的設(shè)計(jì)之外，微信紅包系統(tǒng)添加了一層基于紅包 ID hash 值的分流，如下圖所示其次，設(shè)計(jì)單機(jī)請求排隊(duì)方案。將 stick 到同一臺 Server 上的所有請求在被接

13、收進(jìn)程 接收后，按紅包 ID 進(jìn)行排隊(duì)。然后串行地進(jìn)入 worker 進(jìn)程 進(jìn)行處理，從而達(dá)到排隊(duì)的效果，如下圖所示。最后，增加memcachec控制并發(fā)。為了防止 Server 中的請求隊(duì)列過載導(dǎo)致隊(duì)列被降級，從而所有請求擁進(jìn) DB,系統(tǒng)增加了與 Server服務(wù)器同機(jī)部 署的memcachec，用于控制拆同一個(gè)紅包的請求并發(fā)數(shù)。具體來說，利用 memcached的CAS原子累增操作，控制 同時(shí)進(jìn)入 DB 執(zhí)行拆紅包事務(wù)的請求數(shù)，超過預(yù)先設(shè)定數(shù)值 則直接拒絕服務(wù)。用于 DB負(fù)載升高時(shí)的降級體驗(yàn)。通過以上三個(gè)措施，系統(tǒng)有效地控制了 DB 的“并發(fā)搶 鎖”情況。3. 雙維度庫表設(shè)計(jì)，保障系統(tǒng)性能

14、穩(wěn)定 紅包系統(tǒng)的分庫表規(guī)則，初期是根據(jù)紅包 ID 的 hash 值 分為多庫多表。隨著紅包數(shù)據(jù)量逐漸增大，單表數(shù)據(jù)量也逐 漸增加。而 DB 的性能與單表數(shù)據(jù)量有一定相關(guān)性。當(dāng)單表 數(shù)據(jù)量達(dá)到一定程度時(shí)，DB性能會有大幅度下降， 影響系統(tǒng) 性能穩(wěn)定性。采用冷熱分離，將歷史冷數(shù)據(jù)與當(dāng)前熱數(shù)據(jù)分 開存儲，可以解決這個(gè)問題。處理微信紅包數(shù)據(jù)的冷熱分離時(shí)，系統(tǒng)在以紅包 ID 維 度分庫表的基礎(chǔ)上，增加了以循環(huán)天分表的維度，形成了雙 維度分庫表的特色。具體來說，就是分庫表規(guī)則像db_y_dd 設(shè)計(jì)，其中，xx/y 是紅包 ID 的 hash 值后三位， dd 的取值范圍在 0131， 代表一個(gè)月天數(shù)最多 31 天。通過這種雙維度分庫表方式，解決了 DB 單表數(shù)據(jù)量膨 脹導(dǎo)致性能下降的問題，保障了系統(tǒng)性能的穩(wěn)定性。同時(shí)， 在熱冷分離的問題上，又使得數(shù)據(jù)搬遷變得簡單而優(yōu)雅。綜上所述，微信紅包系統(tǒng)在解決高并發(fā)問題上的設(shè)計(jì)， 主要采用了 SET 化分治、請求排隊(duì)、雙維度分庫表等方案， 使得單組 DB 的并發(fā)性能提升了 8 倍左右，取得了很好的效 果。微信紅包系統(tǒng)是一個(gè)高并發(fā)的資金交易系統(tǒng)，最大的技 術(shù)挑戰(zhàn)