如何進行微信紅包實現原理探討

這篇文章將為大家詳細講解有關如何進行微信紅包實現原理探討，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

一、背景

以下內容基于QCon某高可用架構群討論總結

群里某同學問起微信紅包架構，騰訊財付通同學作出解答，以下實現原理根據對話內容推導得出，不代表官方實現。

實現方式千百種，不追求方法復制，只追求推導過程的思考總結。最后轉了新浪微博Tim總的另一種實現方式。

二、微信紅包實現原理

關鍵設計

• 通過cache抵擋大部分請求（是否能拆紅包等）

• DB使用CAS操作更新紅包計數記錄

• DB、cache使用sharding，可水平擴展

1. 新建紅包

• 在DB、cache各新增一條記錄

2. 搶紅包

• 請求訪問cache，剩余紅包個數大于0則可拆開紅包

3. 拆紅包

• 請求訪問cache，剩余紅包個數大于0則繼續，同時獲取可搶紅包數與金額

• 計算金額（從1分到剩余平均值2倍之間隨機數，如果不是最后一個紅包，剩余金額預留最少1分給cas更新失敗，最后一位拿紅包的人）

• cas更新數據庫（更新紅包計數表記錄【剩余紅包個數、剩余紅包金額】、插入領取記錄）

• 更新失敗，重復以上操作，直到更新成功或已領取完

• 更新成功，更新緩存

DB實現CAS操作偽代碼（說明作用）：

點擊(此處)折疊或打開

1. while (hadHongBao()) {
   

2.     //剩余紅包個數
   

3.     def remainCount = getRemainCount()
   

4.     //實時計算獲取紅包金額
   

5.     def getAmount = calculateAmount()
   

6.     def result = sql.excute("update '紅包計算表' set balance=${total-getAmount}, remainCount=${remainCount-1} where remainCount=${remainCount} and id=${id}")
   

7.     // 更新失敗既繼續執行循環，直到更新成功或已領取完，達到CAS效果
   

8.     if (result > 0) {
   

9.         // 更新成功，執行更新緩存等后續操作
   

10.         // ......
    

11.         break
    

12.     }
    

13. }

DB、cache主要數據結構

1. DB：紅包計數表【主要字段：紅包總金額、紅包總個數、剩余紅包個數、剩余紅包金額】

2. cache：紅包計數記錄【主要字段：剩余紅包個數、剩余紅包金額】

其他補充

注：DB、cache使用sharding，訪問量增大，DB、cache、服務端都可水平擴展。

三、FAQ

上述內容講解了搶紅包關鍵實現原理，更多其他細節請看下述群記錄摘要（以下內容轉載自：https://www.zybuluo.com/yulin718/note/93148）

1. 微信的金額什么時候算？
   答：微信金額是拆的時候實時算出來，不是預先分配的，采用的是純內存計算，不需要預算空間存儲。。
   采取實時計算金額的考慮：預算需要占存儲，實時效率很高，預算才效率低。

2. 實時性：為什么明明搶到紅包，點開后發現沒有？
   答：2014年的紅包一點開就知道金額，分兩次操作，先搶到金額，然后再轉賬。
   2015年的紅包的拆和搶是分離的，需要點兩次，因此會出現搶到紅包了，但點開后告知紅包已經被領完的狀況。進入到第一個頁面不代表搶到，只表示當時紅包還有。

3. 分配：紅包里的金額怎么算？為什么出現各個紅包金額相差很大？
   答：隨機，額度在0.01和剩余平均值2之間。
   例如：發100塊錢，總共10個紅包，那么平均值是10塊錢一個，那么發出來的紅包的額度在0.01元～20元之間波動。
   當前面3個紅包總共被領了40塊錢時，剩下60塊錢，總共7個紅包，那么這7個紅包的額度在：0.01～（60/72）=17.14之間。
   注意：這里的算法是每被搶一個后，剩下的會再次執行上面的這樣的算法（Tim老師也覺得上述算法太復雜，不知基于什么樣的考慮）。
   這樣算下去，會超過最開始的全部金額，因此到了最后面如果不夠這么算，那么會采取如下算法：保證剩余用戶能拿到最低1分錢即可。
   如果前面的人手氣不好，那么后面的余額越多，紅包額度也就越多，因此實際概率一樣的。

4. 紅包的設計
   答：微信從財付通拉取金額數據郭萊，生成個數/紅包類型/金額放到redis集群里，app端將紅包ID的請求放入請求隊列中，如果發現超過紅包的個數，直接返回。根據紅包的裸祭處理成功得到令牌請求，則由財付通進行一致性調用，通過像比特幣一樣，兩邊保存交易記錄，交易后交給第三方服務審計，如果交易過程中出現不一致就強制回歸。

5. 高并發處理：紅包如何計算被搶完？
   答：cache會抵抗無效請求，將無效的請求過濾掉，實際進入到后臺的量不大。cache記錄紅包個數，原子操作進行個數遞減，到0表示被搶光。財付通按照20萬筆每秒入賬準備，但實際還不到8萬每秒。

6. 通如何保持8w每秒的寫入？
   答：多主sharding，水平擴展機器。

7. 據容量多少？
   答：一個紅包只占一條記錄，有效期只有幾天，因此不需要太多空間。

8. 詢紅包分配，壓力大不？
   答：搶到紅包的人數和紅包都在一條cache記錄上，沒有太大的查詢壓力。

9. 一個紅包一個隊列？
   答：沒有隊列，一個紅包一條數據，數據上有一個計數器字段。

10. 有沒有從數據上證明每個紅包的概率是不是均等？
    答：不是絕對均等，就是一個簡單的拍腦袋算法。

11. 拍腦袋算法，會不會出現兩個最佳？
    答：會出現金額一樣的，但是手氣最佳只有一個，先搶到的那個最佳。

12. 每領一個紅包就更新數據么？
    答：每搶到一個紅包，就cas更新剩余金額和紅包個數。

13. 紅包如何入庫入賬？
    數據庫會累加已經領取的個數與金額，插入一條領取記錄。入賬則是后臺異步操作。

14. 入帳出錯怎么辦？比如紅包個數沒了，但余額還有？
    答：最后會有一個take all操作。另外還有一個對賬來保障。

四、另一種實現

群里討論實現原理時，多人提出預分配金額的實現方式（新建紅包時已分配好每一位搶到紅包的金額），減少實時計算及CAS操作的性能損耗，財付通同學說到預分配金額還需要額外存儲空間（更重要的可能是現在的實現方式已滿足需求），后來新浪微博Tim總提出預分配方式不占用額外存儲空間的方式，詳細請看：
<a href="http://timyang.net/architecture/wechat-red-packet/">微信紅包金額分配的算法

實現原理

• 通過保存random seed達到預分配金額效果，既無需記錄剩余紅包金額，只需記錄紅包剩余數

• 搶紅包時，針對紅包剩余數進行DESC原子操作，當紅包剩余數為0既搶完

關于如何進行微信紅包實現原理探討就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。