導語：今天看到有人問：關於微信紅包的隨機演算法！就查閱資料看了一下“微信紅包的架構設計”，自己設計的“公平”的隨機演算法。

實現的程式碼

public static double getRandomMoney(LeftMoneyPackage _leftMoneyPackage) {
    // remainSize 剩餘的紅包數量
    // remainMoney 剩餘的錢
    if (_leftMoneyPackage.remainSize == 1) {
        _leftMoneyPackage.remainSize--;
        return (double
 
) Math.round(_leftMoneyPackage.remainMoney * 100) / 100;
    }
    Random r     = new Random();
    double min   = 0.01; //
    double max   = _leftMoneyPackage.remainMoney / _leftMoneyPackage.remainSize * 2;
    double money = r.nextDouble() * max;
    money = money <= min ? 0.01: money;
    money = Math.floor
 
(money * 100) / 100;
    _leftMoneyPackage.remainSize--;
    _leftMoneyPackage.remainMoney -= money;
    return money;
}

以上程式碼僅供參考。

結論：
1. 先搶後搶拿到紅包的大小的期望是大致相等的，所以還是先下手搶吧
2. 後搶的人方差大（依賴前面人搶的多少），波動較大，有較大機率拿到“手氣最佳”

微信紅包的架構設計簡介

@來源於QCon某高可用架構群整理。

背景：有某個朋友在朋友圈諮詢微信紅包的架構，於是乎有了下面的文字（有誤請提出，謝謝）

概況：2014年微信紅包使用資料庫硬抗整個流量，2015年使用cache抗流量。

1. 微信的金額什麼時候算？

   答：微信金額是拆的時候實時算出來，不是預先分配的，採用的是純記憶體計算，不需要預算空間儲存。
   採取實時計算金額的考慮：預算需要佔儲存，實時效率很高，預算才效率低。

2. 實時性：為什麼明明搶到紅包，點開後發現沒有？

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

3. 分配：紅包裡的金額怎麼算？為什麼出現各個紅包金額相差很大？

   答：隨機，額度在0.01和(剩餘平均值x2)之間。
   例如：發100塊錢，總共10個紅包，那麼平均值是10塊錢一個，那麼發出來的紅包的額度在0.01元～20元之間波動。
   當前面3個紅包總共被領了40塊錢時，剩下60塊錢，總共7個紅包，那麼這7個紅包的額度在：0.01～（60/7*2）=17.14之間。
   注意：這裡的演算法是每被搶一個後，剩下的會再次執行上面的這樣的演算法（Tim老師也覺得上述演算法太複雜，不知基於什麼樣的考慮）。

這樣算下去，會超過最開始的全部金額，因此到了最後面如果不夠這麼算，那麼會採取如下演算法：保證剩餘使用者能拿到最低1分錢即可。

如果前面的人手氣不好，那麼後面的餘額越多，紅包額度也就越多，因此實際概率一樣的。

1. 紅包的設計

   答：微信從財付通拉取金額資料過來，生成個數/紅包型別/金額放到redis叢集裡，app端將紅包ID的請求放入請求佇列中，如果發現超過紅包的個數，直接返回。根據紅包的邏輯處理成功得到令牌請求，則由財付通進行一致性呼叫，通過像比特幣一樣，兩邊儲存交易記錄，交易後交給第三方服務審計，如果交易過程中出現不一致就強制迴歸。

2. 發性處理：紅包如何計算被搶完？

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

3. 通如何保持8w每秒的寫入？

   答：多主sharding，水平擴充套件機器。

4. 據容量多少？

   答：一個紅包只佔一條記錄，有效期只有幾天，因此不需要太多空間。

5. 詢紅包分配，壓力大不？

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

6. 一個紅包一個佇列？

   答：沒有佇列，一個紅包一條資料，資料上有一個計數器欄位。

7. 有沒有從資料上證明每個紅包的概率是不是均等？

   答：不是絕對均等，就是一個簡單的拍腦袋演算法。

8. 拍腦袋演算法，會不會出現兩個最佳？

   答：會出現金額一樣的，但是手氣最佳只有一個，先搶到的那個最佳。

9. 每領一個紅包就更新資料麼？

   答：每搶到一個紅包，就cas更新剩餘金額和紅包個數。

10. 紅包如何入庫入賬？

    資料庫會累加已經領取的個數與金額，插入一條領取記錄。入賬則是後臺非同步操作。

11. 入帳出錯怎麼辦？比如紅包個數沒了，但餘額還有？

    答：最後會有一個take all操作。另外還有一個對賬來保障。