- 相關(guān)推薦
系統實(shí)現方案設計
設計要確定設計方案，首先要清楚設計的目的和所要達到的效果。下面小編給大家帶來(lái)系統實(shí)現方案設計，歡迎大家閱讀。
背景介紹
2017年1月28日，正月初一，微信公布了用戶(hù)在除夕當天收發(fā)微信紅包的數量——142億個(gè)，而其收發(fā)峰值也已達到76萬(wàn)每秒。百億級別的紅包，如何保障并發(fā)性能與資金安全？這給微信帶來(lái)了超級挑戰。面對挑戰，微信紅包在分析了業(yè)界“秒殺”系統解決方案的基礎上，采用了SET化、請求排隊串行化、雙維度分庫表等設計，形成了獨特的高并發(fā)、資金安全系統解決方案。實(shí)踐證明，該方案表現穩定，且實(shí)現了除夕夜系統零故障運行。
本文將為讀者介紹百億級別紅包背后的系統高并發(fā)設計方案，包括微信紅包的兩大業(yè)務(wù)特點(diǎn)、微信紅包系統的技術(shù)難點(diǎn)、解決高并發(fā)問(wèn)題通常使用的方案，以及微信紅包系統的高并發(fā)解決方案。
微信紅包的兩大業(yè)務(wù)特點(diǎn)
微信紅包（尤其是發(fā)在微信群里的紅包，即群紅包）業(yè)務(wù)形態(tài)上很類(lèi)似網(wǎng)上的普通商品“秒殺”活動(dòng)。
用戶(hù)在微信群里發(fā)一個(gè)紅包，等同于是普通商品“秒殺”活動(dòng)的商品上架；微信群里的所有用戶(hù)搶紅包的動(dòng)作，等同于“秒殺”活動(dòng)中的查詢(xún)庫存；用戶(hù)搶到紅包后拆紅包的動(dòng)作，則對應“秒殺”活動(dòng)中用戶(hù)的“秒殺”動(dòng)作。
不過(guò)除了上面的相同點(diǎn)之外，微信紅包在業(yè)務(wù)形態(tài)上與普通商品“秒殺”活動(dòng)相比，還具備自身的特點(diǎn)：
首先，微信紅包業(yè)務(wù)比普通商品“秒殺”有更海量的并發(fā)要求。
微信紅包用戶(hù)在微信群里發(fā)一個(gè)紅包，等同于在網(wǎng)上發(fā)布一次商品“秒殺”活動(dòng)。假設同一時(shí)間有10萬(wàn)個(gè)群里的用戶(hù)同時(shí)在發(fā)紅包，那就相當于同一時(shí)間有10萬(wàn)個(gè)“秒殺”活動(dòng)發(fā)布出去。10萬(wàn)個(gè)微信群里的用戶(hù)同時(shí)搶紅包，將產(chǎn)生海量的并發(fā)請求。
其次，微信紅包業(yè)務(wù)要求更嚴格的安全級別。
微信紅包業(yè)務(wù)本質(zhì)上是資金交易。微信紅包是微信支付的一個(gè)商戶(hù)，提供資金流轉服務(wù)。
用戶(hù)發(fā)紅包時(shí)，相當于在微信紅包這個(gè)商戶(hù)上使用微信支付購買(mǎi)一筆“錢(qián)”，并且收貨地址是微信群。當用戶(hù)支付成功后，紅包“發(fā)貨”到微信群里，群里的用戶(hù)拆開(kāi)紅包后，微信紅包提供了將“錢(qián)”轉入折紅包用戶(hù)微信零錢(qián)的服務(wù)。
資金交易業(yè)務(wù)比普通商品“秒殺”活動(dòng)有更高的安全級別要求。普通的商品“秒殺”商品由商戶(hù)提供，庫存是商戶(hù)預設的，“秒殺”時(shí)可以允許存在“超賣(mài)”（即實(shí)際被搶的商品數量比計劃的庫存多）、“少賣(mài)”（即實(shí)際被搶的商戶(hù)數量比計劃的庫存少）的情況。但是對于微信紅包，用戶(hù)發(fā)100元的紅包絕對不可以被拆出101元；用戶(hù)發(fā)100元只被領(lǐng)取99元時(shí)，剩下的1元在24小時(shí)過(guò)期后要精確地退還給發(fā)紅包用戶(hù)，不能多也不能少。
以上是微信紅包業(yè)務(wù)模型上的兩大特點(diǎn)。
微信紅包系統的技術(shù)難點(diǎn)
在介紹微信紅包系統的技術(shù)難點(diǎn)之前，先介紹下簡(jiǎn)單的、典型的商品“秒殺”系統的架構設計，如下圖所示。
該系統由接入層、邏輯服務(wù)層、存儲層與緩存構成。Proxy處理請求接入，Server承載主要的業(yè)務(wù)邏輯，Cache用于緩存庫存數量、DB則用于數據持久化。
一個(gè)“秒殺”活動(dòng)，對應DB中的一條庫存記錄。當用戶(hù)進(jìn)行商品“秒殺”時(shí)，系統的主要邏輯在于DB中庫存的操作上。一般來(lái)說(shuō)，對DB的操作流程有以下三步：
鎖庫存
插入“秒殺”記錄
更新庫存
其中，鎖庫存是為了避免并發(fā)請求時(shí)出現“超賣(mài)”情況。同時(shí)要求這三步操作需要在一個(gè)事務(wù)中完成（所謂的事務(wù)，是指作為單個(gè)邏輯工作單元執行的一系列操作，要么完全地執行，要么完全地不執行）。
“秒殺”系統的設計難點(diǎn)就在這個(gè)事務(wù)操作上。商品庫存在DB中記為一行，大量用戶(hù)同時(shí)“秒殺”同一商品時(shí)，第一個(gè)到達DB的請求鎖住了這行庫存記錄。在第一個(gè)事務(wù)完成提交之前這個(gè)鎖一直被第一個(gè)請求占用，后面的所有請求需要排隊等待。同時(shí)參與“秒殺”的用戶(hù)越多，并發(fā)進(jìn)DB的請求越多，請求排隊越嚴重。因此，并發(fā)請求搶鎖，是典型的商品“秒殺”系統的設計難點(diǎn)。
微信紅包業(yè)務(wù)相比普通商品“秒殺”活動(dòng)，具有海量并發(fā)、高安全級別要求的特點(diǎn)。在微信紅包系統的設計上，除了并發(fā)請求搶鎖之外，還有以下兩個(gè)突出難點(diǎn)：
首先，事務(wù)級操作量級大。上文介紹微信紅包業(yè)務(wù)特點(diǎn)時(shí)提到，普遍情況下同時(shí)會(huì )有數以萬(wàn)計的微信群在發(fā)紅包。這個(gè)業(yè)務(wù)特點(diǎn)映射到微信紅包系統設計上，就是有數以萬(wàn)計的“并發(fā)請求搶鎖”同時(shí)在進(jìn)行。這使得DB的壓力比普通單個(gè)商品“庫存”被鎖要大很多倍。
其次，事務(wù)性要求嚴格。微信紅包系統本質(zhì)上是一個(gè)資金交易系統，相比普通商品“秒殺”系統有更高的事務(wù)級別要求。
解決高并發(fā)問(wèn)題常用方案
普通商品“秒殺”活動(dòng)系統，解決高并發(fā)問(wèn)題的方案，大體有以下幾種：
方案一，使用內存操作替代實(shí)時(shí)的DB事務(wù)操作。
如圖2所示，將“實(shí)時(shí)扣庫存”的行為上移到內存Cache中操作，內存Cache操作成功直接給Server返回成功，然后異步落DB持久化。
這個(gè)方案的優(yōu)點(diǎn)是用內存操作替代磁盤(pán)操作，提高了并發(fā)性能。
但是缺點(diǎn)也很明顯，在內存操作成功但DB持久化失敗，或者內存Cache故障的情況下，DB持久化會(huì )丟數據，不適合微信紅包這種資金交易系統。
方案二，使用樂(lè )觀(guān)鎖替代悲觀(guān)鎖。
所謂悲觀(guān)鎖，是關(guān)系數據庫管理系統里的一種并發(fā)控制的方法。它可以阻止一個(gè)事務(wù)以影響其他用戶(hù)的方式來(lái)修改數據。如果一個(gè)事務(wù)執行的操作對某行數據應用了鎖，那只有當這個(gè)事務(wù)把鎖釋放，其他事務(wù)才能夠執行與該鎖沖突的操作。對應于上文分析中的“并發(fā)請求搶鎖”行為。
所謂樂(lè )觀(guān)鎖，它假設多用戶(hù)并發(fā)的事務(wù)在處理時(shí)不會(huì )彼此互相影響，各事務(wù)能夠在不產(chǎn)生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前，每個(gè)事務(wù)會(huì )先檢查在該事務(wù)讀取數據后，有沒(méi)有其他事務(wù)又修改了該數據。如果其他事務(wù)有更新的話(huà)，正在提交的事務(wù)會(huì )進(jìn)行回滾。
商品“秒殺”系統中，樂(lè )觀(guān)鎖的具體應用方法，是在DB的“庫存”記錄中維護一個(gè)版本號。在更新“庫存”的操作進(jìn)行前，先去DB獲取當前版本號。在更新庫存的事務(wù)提交時(shí)，檢查該版本號是否已被其他事務(wù)修改。如果版本沒(méi)被修改，則提交事務(wù)，且版本號加1；如果版本號已經(jīng)被其他事務(wù)修改，則回滾事務(wù)，并給上層報錯。
這個(gè)方案解決了“并發(fā)請求搶鎖”的問(wèn)題，可以提高DB的并發(fā)處理能力。
但是如果應用于微信紅包系統，則會(huì )存在下面三個(gè)問(wèn)題：
如果拆紅包采用樂(lè )觀(guān)鎖，那么在并發(fā)搶到相同版本號的拆紅包請求中，只有一個(gè)能拆紅包成功，其他的請求將事務(wù)回滾并返回失敗，給用戶(hù)報錯，用戶(hù)體驗完全不可接受。
如果采用樂(lè )觀(guān)鎖，將會(huì )導致第一時(shí)間同時(shí)拆紅包的用戶(hù)有一部分直接返回失敗，反而那些“手慢”的用戶(hù)，有可能因為并發(fā)減小后拆紅包成功，這會(huì )帶來(lái)用戶(hù)體驗上的負面影響。
如果采用樂(lè )觀(guān)鎖的方式，會(huì )帶來(lái)大數量的無(wú)效更新請求、事務(wù)回滾，給DB造成不必要的額外壓力。
基于以上原因，微信紅包系統不能采用樂(lè )觀(guān)鎖的方式解決并發(fā)搶鎖問(wèn)題。
微信紅包系統的高并發(fā)解決方案
綜合上面的分析，微信紅包系統針對相應的技術(shù)難點(diǎn)，采用了下面幾個(gè)方案，解決高并發(fā)問(wèn)題。
1.系統垂直SET化，分而治之。
微信紅包用戶(hù)發(fā)一個(gè)紅包時(shí)，微信紅包系統生成一個(gè)ID作為這個(gè)紅包的唯一標識。接下來(lái)這個(gè)紅包的所有發(fā)紅包、搶紅包、拆紅包、查詢(xún)紅包詳情等操作，都根據這個(gè)ID關(guān)聯(lián)。
紅包系統根據這個(gè)紅包ID，按一定的規則（如按ID尾號取模等），垂直上下切分。切分后，一個(gè)垂直鏈條上的邏輯Server服務(wù)器、DB統稱(chēng)為一個(gè)SET。
各個(gè)SET之間相互獨立，互相解耦。并且同一個(gè)紅包ID的所有請求，包括發(fā)紅包、搶紅包、拆紅包、查詳情詳情等，垂直stick到同一個(gè)SET內處理，高度內聚。通過(guò)這樣的方式，系統將所有紅包請求這個(gè)巨大的洪流分散為多股小流，互不影響，分而治之，如下圖所示。
這個(gè)方案解決了同時(shí)存在海量事務(wù)級操作的問(wèn)題，將海量化為小量。
2.邏輯Server層將請求排隊，解決DB并發(fā)問(wèn)題。
紅包系統是資金交易系統，DB操作的事務(wù)性無(wú)法避免，所以會(huì )存在“并發(fā)搶鎖”問(wèn)題。但是如果到達DB的事務(wù)操作（也即拆紅包行為）不是并發(fā)的，而是串行的，就不會(huì )存在“并發(fā)搶鎖”的問(wèn)題了。
按這個(gè)思路，為了使拆紅包的事務(wù)操作串行地進(jìn)入DB，只需要將請求在Server層以FIFO（先進(jìn)先出）的方式排隊，就可以達到這個(gè)效果。從而問(wèn)題就集中到Server的FIFO隊列設計上。
微信紅包系統設計了分布式的、輕巧的、靈活的FIFO隊列方案。其具體實(shí)現如下：
首先，將同一個(gè)紅包ID的所有請求stick到同一臺Server。
上面SET化方案已經(jīng)介紹，同個(gè)紅包ID的所有請求，按紅包ID stick到同個(gè)SET中。不過(guò)在同個(gè)SET中，會(huì )存在多臺Server服務(wù)器同時(shí)連接同一臺DB（基于容災、性能考慮，需要多臺Server互備、均衡壓力）。
為了使同一個(gè)紅包ID的所有請求，stick到同一臺Server服務(wù)器上，在SET化的設計之外，微信紅包系統添加了一層基于紅包ID hash值的分流，如下圖所示。
其次，設計單機請求排隊方案。
將stick到同一臺Server上的所有請求在被接收進(jìn)程接收后，按紅包ID進(jìn)行排隊。然后串行地進(jìn)入worker進(jìn)程（執行業(yè)務(wù)邏輯）進(jìn)行處理，從而達到排隊的效果，如下圖所示。
最后，增加memcached控制并發(fā)。
為了防止Server中的請求隊列過(guò)載導致隊列被降級，從而所有請求擁進(jìn)DB，系統增加了與Server服務(wù)器同機部署的memcached，用于控制拆同一個(gè)紅包的請求并發(fā)數。
具體來(lái)說(shuō)，利用memcached的CAS原子累增操作，控制同時(shí)進(jìn)入DB執行拆紅包事務(wù)的請求數，超過(guò)預先設定數值則直接拒絕服務(wù)。用于DB負載升高時(shí)的降級體驗。
通過(guò)以上三個(gè)措施，系統有效地控制了DB的“并發(fā)搶鎖”情況。
3.雙維度庫表設計，保障系統性能穩定
紅包系統的分庫表規則，初期是根據紅包ID的hash值分為多庫多表。隨著(zhù)紅包數據量逐漸增大，單表數據量也逐漸增加。而DB的性能與單表數據量有一定相關(guān)性。當單表數據量達到一定程度時(shí)，DB性能會(huì )有大幅度下降，影響系統性能穩定性。采用冷熱分離，將歷史冷數據與當前熱數據分開(kāi)存儲，可以解決這個(gè)問(wèn)題。
處理微信紅包數據的冷熱分離時(shí)，系統在以紅包ID維度分庫表的基礎上，增加了以循環(huán)天分表的維度，形成了雙維度分庫表的特色。
具體來(lái)說(shuō)，就是分庫表規則像db_xx.t_y_dd設計，其中，xx/y是紅包ID的hash值后三位，dd的取值范圍在01~31，代表一個(gè)月天數最多31天。
通過(guò)這種雙維度分庫表方式，解決了DB單表數據量膨脹導致性能下降的問(wèn)題，保障了系統性能的穩定性。同時(shí)，在熱冷分離的問(wèn)題上，又使得數據搬遷變得簡(jiǎn)單而優(yōu)雅。
綜上所述，微信紅包系統在解決高并發(fā)問(wèn)題上的設計，主要采用了SET化分治、請求排隊、雙維度分庫表等方案，使得單組DB的并發(fā)性能提升了8倍左右，取得了很好的效果。
最后總結
微信紅包系統是一個(gè)高并發(fā)的資金交易系統，最大的技術(shù)挑戰是保障并發(fā)性能與資金安全。這種全新的技術(shù)挑戰，傳統的“秒殺”系統設計方案已不能完全解決。在分析了業(yè)界“秒殺”系統解決方案的基礎上，微信紅包采用了SET化、請求排隊串行化、雙維度分庫表等設計，形成了獨特的高并發(fā)、資金安全系統解決方案，并在平時(shí)節假日、2015和2016春節實(shí)踐中充分證明了可行性，取得了顯著(zhù)的效果。在剛剛過(guò)去的2017雞年除夕夜，微信紅包收發(fā)峰值達到76萬(wàn)每秒，收發(fā)微信紅包142億個(gè)，微信紅包系統的表現穩定，實(shí)現了除夕夜系統零故障
【系統實(shí)現方案設計】相關(guān)文章：
論多媒體創(chuàng )作系統的設計與實(shí)現07-05
煙臺銷(xiāo)售HR系統實(shí)現單軌運行07-03
淺談多媒體教學(xué)系統的設計與實(shí)現07-01
基于Web的網(wǎng)絡(luò )考試系統設計與實(shí)現論文07-03
客戶(hù)關(guān)系管理系統的設計與實(shí)現分析參考07-01