微信紅包隨機演算法初探

阿新 • • 發佈：2019-01-01

最近看了一篇文章，講微信紅包隨機演算法的。感覺很不錯，所以自己實現了下，並進行了簡單測試。

演算法

演算法很簡單，不是提前算好，而是搶紅包時計算：

紅包裡的金額怎麼算？為什麼出現各個紅包金額相差很大？
答：隨機，額度在0.01和剩餘平均值*2之間。

實現

實現上述演算法的邏輯主要是：

public static double getRandomMoney(LeftMoneyPackage _leftMoneyPackage) {
    if (_leftMoneyPackage.peoples == 1) {
        _leftMoneyPackage.peoples--;
        return 
 (double) Math.round(_leftMoneyPackage.leftMoney * 100) / 100;
    }
    Random r     = new Random();
    double min   = 0.01;
    double max   = _leftMoneyPackage.leftMoney / _leftMoneyPackage.peoples * 2;
    double money = r.nextDouble() * max;
    money = money < min ? min : money;
    money = (double 
) Math.floor(money * 100) / 100;
    _leftMoneyPackage.peoples--;
    _leftMoneyPackage.leftMoney -= money;
    return money;
}

LeftMoneyPackage資料結構如下：

class LeftMoneyPackage {
    int    peoples;
    double leftMoney;
}

測試時初始化相關資料是：

static void init() {
    leftMoneyPackage.peoples = 30;
    leftMoneyPackage.leftMoney = 500 
;
}

測試結果

單詞測試隨機紅包

以上面的初始化資料（30人搶500塊），執行了兩次，結果如下：

// 第一次
15.69    21.18    24.11    30.85    0.74    20.85    2.96    13.43    11.12    24.87    1.86    19.62    5.97    29.33    3.05    26.94    18.69    34.47    9.4    29.83    5.17    24.67    17.09    29.96    6.77    5.79    0.34    23.89    40.44    0.92

// 第二次
10.44    18.01    17.01    21.07    11.87    4.78    30.14    32.05    16.68    20.34    12.94    27.98    9.31    17.97    12.93    28.75    12.1    12.77    7.54    10.87    4.16    25.36    26.89    5.73    11.59    23.91    17.77    15.85    23.42    9.77

對應圖表如下：

還有一張：

多次均值

可以看到，這個演算法可以讓大家搶到的紅包面額在概率上是大致均勻的。

轉一下原文

微信紅包的架構設計簡介

@來源於QCon某高可用架構群整理，整理朱玉華。

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

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

微信的金額什麼時候算？

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

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

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

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

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

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

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

紅包的設計

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

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

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

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

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

據容量多少？

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

詢紅包分配，壓力大不？

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

一個紅包一個佇列？

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

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

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

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

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

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

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

紅包如何入庫入賬？

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

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

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