關(guān)于微信紅包的架構(gòu)思考

微信紅包的架構(gòu)實現(xiàn)是前段時間技術(shù)圈里很熱門的一個話題，這是一個非常典型的大訪問高并發(fā)場景。至于如何實現(xiàn)，答案并不是唯一的，對這個問題的思考其實反映了工程師的架構(gòu)設(shè)計功底。所以我也談一談我的想法。

首先任何架構(gòu)設(shè)計離不開對業(yè)務(wù)的理解和認(rèn)識，架構(gòu)設(shè)計并不是憑空存在的，一定是基于業(yè)務(wù)場景并且服務(wù)業(yè)務(wù)場景的。所以我先分析一下微信紅包的業(yè)務(wù)場景。

---

*** 需要特別說一點，本文中的架構(gòu)設(shè)計不一定是官方的實現(xiàn)方式，只是一種分析，是基于我目前的技術(shù)能力的一種思考 ***

---

業(yè)務(wù)場景分析

根據(jù)微信紅包的操作，可以把紅包的業(yè)務(wù)場景分為發(fā)放紅包，搶紅包和打開紅包三個步驟。
PS:我覺得微信紅包的架構(gòu)討論之所以非常火爆，一個重要原因就是微信紅包的業(yè)務(wù)場景大家都很熟悉

發(fā)放紅包:

• 發(fā)放者設(shè)置紅包金額，紅包數(shù)量等屬性
• 從發(fā)放者賬戶扣除紅包金額
• 生成紅包，并且發(fā)送搶紅包的鏈接

搶紅包:

• 用戶點擊紅包鏈接

打開紅包:

• 顯示用戶搶到的紅包金額
• 剩余紅包數(shù)量-１，紅包剩余金額改變
• 搶到紅包的用戶賬戶金額增加

注意，以上均為原子操作

根據(jù)業(yè)務(wù)場景，可以知道紅包的主要屬性有：

• 紅包金額：始終不變
• 紅包總數(shù)量：始終不變
• 紅包剩余金額：每次有人領(lǐng)取紅包，該屬性變化
• 紅包剩余數(shù)量：每次有人領(lǐng)取紅包，該屬性－１
• 搶到紅包的用戶以及搶到的金額：用于顯示手氣排行，并且防止重復(fù)搶紅包
• 過期時間：如果到過期紅包仍未搶完，返回發(fā)放者賬戶

架構(gòu)分析

單純實現(xiàn)微信紅包的功能并不復(fù)雜，其難點在于如何處理高訪問和并發(fā)，當(dāng)發(fā)出一個紅包之后，只有少數(shù)人能夠搶到，而大部分的請求都屬于無效請求，如果讓這部分請求落到數(shù)據(jù)庫或者在服務(wù)端經(jīng)過復(fù)雜處理，那么以微信的用戶體量，后果是災(zāi)難性的。

從這個角度來說，微信紅包和電商的秒殺業(yè)務(wù)有幾分相似

處理類似業(yè)務(wù)最常見的手段就是請求過濾和添加緩存(cache)，當(dāng)然，至于服務(wù)器集群，負(fù)載均衡，讀寫分離這些基礎(chǔ)架構(gòu)，由于已經(jīng)成了大型網(wǎng)站的標(biāo)配，默認(rèn)已經(jīng)存在。

其中，請求過濾是只允許少數(shù)符合條件的請求走到最后，把大量不符合條件的請求擋在外面，這個非常關(guān)鍵。而采用緩存技術(shù)，原因有兩個，一是緩存的訪問速度快，使用緩存可以有效提高吞吐速度，二是紅包發(fā)放相對來說是一個臨時性的東西，故而可以放在緩存里面。

業(yè)務(wù)上需要注意的地方

• 防止用戶重復(fù)搶紅包
• 應(yīng)對redis宕機的風(fēng)險，目前一般是采用sentinel機制

架構(gòu)設(shè)計

緩存我們默認(rèn)使用redis，數(shù)據(jù)庫默認(rèn)使用mysql

新建紅包的時候，生成唯一紅包id，設(shè)置紅包屬性，在mysql中添加記錄，表結(jié)構(gòu)大致如下

|紅包id|發(fā)放者uid|紅包總金額|紅包總數(shù)量|紅包剩余金額|紅包剩余數(shù)量|搶到紅包的用戶列表json|過期時間|創(chuàng)建時間|
|---|:----|:---|---|----|---|---|----|---|--|--|:---|:----|:---|---|----|---|---|----|---|--

同時，在redis里添加：

• 搶紅包請求隊列(隊列)
• 打開紅包請求隊列(隊列)
• 紅包信息，包含剩余紅包數(shù)量和剩余金額(鍵值對)
• 已經(jīng)搶到紅包的用戶信息(有序集合)

當(dāng)搶紅包的時候，
做以下判斷：

• 剩余紅包數(shù)量是否大于0
• 該用戶是否在已經(jīng)搶到紅包的用戶集合里面
  通過判斷的請求添加進(jìn)請求隊列，否則返回已經(jīng)搶完的標(biāo)示，這樣下一步用戶打開紅包的時候，甚至可以不發(fā)送請求直接顯示紅包已經(jīng)搶完，過濾無效請求

于此同時，另外有進(jìn)程從請求隊列里取出搶紅包請求，生成token標(biāo)示，返回給搶紅包者

當(dāng)用戶打開紅包的時候，傳入該標(biāo)示，放進(jìn)打開紅包請求隊列，后端消費者進(jìn)程從隊列中取出打開紅包請求，判斷紅包數(shù)量是否大于0，以及用戶傳來的打開紅包token與紅包id是否合法，參數(shù)檢驗之后，生成紅包金額，調(diào)用余額接口處理，并且更新redis中紅包剩余數(shù)量，紅包剩余金額

最后異步方式更新數(shù)據(jù)庫

紅包算法

關(guān)于紅包算法，網(wǎng)上說的很多了，這里就不啰嗦了，金額是拆的時候?qū)崟r算出來，不是預(yù)先分配的，采用的是純內(nèi)存計算，不需要預(yù)算空間存儲，具體的算法是在在0.01和剩余平均值的2倍之間隨機生成一個金額

效果

比如現(xiàn)在發(fā)了一個紅包，分為5份。有100個人搶。

可能有10個人成功進(jìn)入請求隊列（搶到紅包和打開紅包之間有一定間隔，所以先搶到的不一定先打開），拿到了打開紅包token，其余90個人拿到的是紅包已經(jīng)搶完的token，那么當(dāng)打開紅包的時候，這90個人甚至都不需要發(fā)送請求，直接顯示紅包已搶完

這10個人打開紅包的時候，其中5個人搶到，剩下的5個也顯示紅包已經(jīng)搶完

本來5個紅包100個人搶，會請求201次(生成紅包1次+搶紅包100次+打開紅包100次)
那么這種情況下，只需要111次(生成紅包1次+搶紅包100次+打開紅包10次)，并且，其中90次請求很快就返回，大大減輕服務(wù)端壓力

需要注意的是

• 如何保證原子性操作
• 如何提高可用性，主要是防止redis宕機

總結(jié)

衡量一個架構(gòu)設(shè)計的標(biāo)準(zhǔn)主要是性能，擴展性，伸縮性，可用性，安全性等指標(biāo)，本例中，由于紅包業(yè)務(wù)是一個很具體的業(yè)務(wù)，并非通用服務(wù)，所以不討論擴展性。

• 性能角度，由于采用了緩存以及請求過濾等手段，性能肯定比常規(guī)實現(xiàn)大大提高
• 伸縮性角度，應(yīng)該采用服務(wù)器集群，redis集群，mysql集群的方式部署，注意redis集群中的一致性hash的實現(xiàn)
• 可用性角度，本例中決定可用性的關(guān)鍵還是在于redis集群是否能夠保證高可用，所以sentinel機制必不可少，甚至還應(yīng)該加上其他的各種檢測節(jié)點，替換節(jié)點方案，以保證高可用。而且需要考慮極端情況，例如緩存被擊穿導(dǎo)致mysql壓力過大的情況下，如何確保服務(wù)不宕機。
• 安全性角度，紅包涉及資金來往，所以需要格外注意安全性。紅包業(yè)務(wù)中，是通過調(diào)用接口來實現(xiàn)資金往來，故賬目平衡的風(fēng)險不是由紅包系統(tǒng)來承擔(dān)而是由紅包所調(diào)用的接口保證的，但紅包系統(tǒng)也可能存在以下幾種安全隱患，單一用戶重復(fù)搶紅包，所有用戶搶的的紅包金額總數(shù)大于發(fā)放者設(shè)置的紅包金額等。所以其關(guān)鍵在于確保搶紅包，打開紅包均為一次原子性操作。如有必要，甚至可以通過加鎖等方式實現(xiàn)，但需要考慮加鎖對于性能上的影響

作者：cuihang
鏈接：https://www.jianshu.com/p/63f238b04c59
來源：簡書
簡書著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請聯(lián)系作者獲得授權(quán)并注明出處。

總結(jié)

以上是生活随笔為你收集整理的关于微信红包的架构思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。