一、背景
以下内容基于QCon某高可用架構群讨論總結
群裡某同學問起微信紅包架構，騰訊财付通同學作出解答，以下實作原理根據對話内容推導得出，不代表官方實作。
實作方式千百種，不追求方法複制，隻追求推導過程的思考總結。最後轉了新浪微網誌Tim總的另一種實作方式。
二、微信紅包實作原理
關鍵設計
通過cache抵擋大部分請求(是否能拆紅包等)
DB使用CAS操作更新紅包計數記錄
DB、cache使用sharding，可水準擴充
1. 建立紅包
在DB、cache各新增一條記錄
2. 搶紅包
請求通路cache，剩餘紅包個數大于0則可拆開紅包
3. 拆紅包
請求通路cache，剩餘紅包個數大于0則繼續，同時擷取可搶紅包數與金額
計算金額(從1分到剩餘平均值2倍之間随機數，如果不是最後一個紅包，剩餘金額預留最少1分給cas更新失敗，最後一位拿紅包的人)
cas更新資料庫(更新紅包計數表記錄【剩餘紅包個數、剩餘紅包金額】、插入領取記錄)
更新失敗，重複以上操作，直到更新成功或已領取完
更新成功，更新緩存
DB實作CAS操作僞代碼(說明作用)：
while (hadHongBao()) {
//剩餘紅包個數
def remainCount = getRemainCount()
//實時計算擷取紅包金額
def getAmount = calculateAmount()
def result = sql.excute("update '紅包計算表' set balance=${total-getAmount}, remainCount=${remainCount-1} where remainCount=${remainCount} and id=${id}")
// 更新失敗既繼續執行循環，直到更新成功或已領取完，達到CAS效果
if (result > 0) {
// 更新成功，執行更新緩存等後續操作
// ......
break
}
}
DB、cache主要資料結構
DB：紅包計數表【主要字段：紅包總金額、紅包總個數、剩餘紅包個數、剩餘紅包金額】
cache：紅包計數記錄【主要字段：剩餘紅包個數、剩餘紅包金額】
其他補充
注：DB、cache使用sharding，通路量增大，DB、cache、服務端都可水準擴充。
三、FAQ
微信的金額什麼時候算？
答：微信金額是拆的時候實時算出來，不是預先配置設定的，采用的是純記憶體計算，不需要預算空間存儲。。
采取實時計算金額的考慮：預算需要占存儲，實時效率很高，預算才效率低。
實時性：為什麼明明搶到紅包，點開後發現沒有？
答：2014年的紅包一點開就知道金額，分兩次操作，先搶到金額，然後再轉賬。
2015年的紅包的拆和搶是分離的，需要點兩次，是以會出現搶到紅包了，但點開後告知紅包已經被領完的狀況。進入到第一個頁面不代表搶到，隻表示當時紅包還有。
配置設定：紅包裡的金額怎麼算？為什麼出現各個紅包金額相差很大？
答：随機，額度在0.01和剩餘平均值2之間。
例如：發100塊錢，總共10個紅包，那麼平均值是10塊錢一個，那麼發出來的紅包的額度在0.01元～20元之間波動。
目前面3個紅包總共被領了40塊錢時，剩下60塊錢，總共7個紅包，那麼這7個紅包的額度在：0.01～(60/72)=17.14之間。
注意：這裡的算法是每被搶一個後，剩下的會再次執行上面的這樣的算法(Tim老師也覺得上述算法太複雜，不知基于什麼樣的考慮)。
這樣算下去，會超過最開始的全部金額，是以到了最後面如果不夠這麼算，那麼會采取如下算法：保證剩餘使用者能拿到最低1分錢即可。
如果前面的人手氣不好，那麼後面的餘額越多，紅包額度也就越多，是以實際機率一樣的。
紅包的設計
答：微信從财付通拉取金額資料郭萊，生成個數/紅包類型/金額放到redis叢集裡，app端将紅包ID的請求放入請求隊列中，如果發現超過紅包的個數，直接傳回。根據紅包的裸祭處理成功得到令牌請求，則由财付通進行一緻性調用，通過像比特币一樣，兩邊儲存交易記錄，交易後交給第三方服務審計，如果交易過程中出現不一緻就強制回歸。
高并發處理：紅包如何計算被搶完？
答：cache會抵抗無效請求，将無效的請求過濾掉，實際進入到背景的量不大。cache記錄紅包個數，原子操作進行個數遞減，到0表示被搶光。财付通按照20萬筆每秒入賬準備，但實際還不到8萬每秒。
通如何保持8w每秒的寫入？
答：多主sharding，水準擴充機器。
據容量多少？
答：一個紅包隻占一條記錄，有效期隻有幾天，是以不需要太多空間。
詢紅包配置設定，壓力大不？
答：搶到紅包的人數和紅包都在一條cache記錄上，沒有太大的查詢壓力。
一個紅包一個隊列？
答：沒有隊列，一個紅包一條資料，資料上有一個計數器字段。
有沒有從資料上證明每個紅包的機率是不是均等？
答：不是絕對均等，就是一個簡單的拍腦袋算法。
拍腦袋算法，會不會出現兩個最佳？
答：會出現金額一樣的，但是手氣最佳隻有一個，先搶到的那個最佳。
每領一個紅包就更新資料麼？
答：每搶到一個紅包，就cas更新剩餘金額和紅包個數。
紅包如何入庫入賬？
資料庫會累加已經領取的個數與金額，插入一條領取記錄。入賬則是背景異步操作。
入帳出錯怎麼辦？比如紅包個數沒了，但餘額還有？
答：最後會有一個take all操作。另外還有一個對賬來保障。
四、另一種實作
群裡讨論實作原理時，多人提出預配置設定金額的實作方式(建立紅包時已配置設定好每一位搶到紅包的金額)，減少實時計算及CAS操作的性能損耗，财付通同學說到預配置設定金額還需要額外存儲空間(更重要的可能是現在的實作方式已滿足需求)，後來新浪微網誌Tim總提出預配置設定方式不占用額外存儲空間的方式，詳細請看：
微信紅包金額配置設定的算法
實作原理
通過儲存random seed達到預配置設定金額效果，既無需記錄剩餘紅包金額，隻需記錄紅包剩餘數
搶紅包時，針對紅包剩餘數進行DESC原子操作，當紅包剩餘數為0既搶完