微信红包随机数字_微信红包的随机算法
概況：2014年微信紅包使用數據庫硬抗整個流量，2015年使用cache抗流量。
微信金額是拆的時候實時算出來，不是預先分配的，采用的是純內存計算，不需要預算空間存儲。采取實時計算金額的考慮：預算需要占存儲，實時效率很高，預算才效率低。
算法：
算法很簡單，因為微信不會將紅包的算法開源，所以，這是基于部分樣本提取出的特征以及網上的資源猜測出的算法。
很簡單：
基于截尾正態分布，數額隨機，額度在0.01和剩余平均值*2之間。
實現上述算法的邏輯主要是：
public staticBigDecimal getRandomMoney(RedPackage redPackage) {//remainSize 剩余的紅包數量//remainMoney 剩余的錢
int remainSize =redPackage.getRemainSize();
BigDecimal remainMoney=redPackage.getRemainMoney();if (remainSize == 1) {
remainSize--;
redPackage.setRemainSize(remainSize);
redPackage.setRemainMoney(BigDecimal.ZERO);returnremainMoney;
}
Random r= newRandom();
BigDecimal min= new BigDecimal(0.01);
BigDecimal max= remainMoney.divide(new BigDecimal(remainSize * 2), 2, RoundingMode.HALF_UP);
BigDecimal money= max.multiply(newBigDecimal(r.nextInt()));if (money.compareTo(new BigDecimal(0.01)) < 0) {
money= new BigDecimal(0.01);
}
remainSize--;
remainMoney=remainMoney.subtract(money);
redPackage.setRemainSize(remainSize);
redPackage.setRemainMoney(remainMoney);returnmoney;
}
RedPackage數據結構如下：
public classRedPackage {private intremainSize;privateBigDecimal remainMoney;public intgetRemainSize() {returnremainSize;
}public void setRemainSize(intremainSize) {this.remainSize =remainSize;
}publicBigDecimal getRemainMoney() {returnremainMoney;
}public voidsetRemainMoney(BigDecimal remainMoney) {this.remainMoney =remainMoney;
}
}
測試時初始化相關數據是：
remainSize = 30;
remainMoney= 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
對應圖表如下：
第一次：
第二次：
200次：
2000次：
為什么不采用完全隨機的辦法？
這種產生機理不好的地方在于：大多數人得到的錢非常少，而極少數人得到的錢卻非常多，而這可能會對抽取人的積極性產生影響。截尾正態分布能夠更好地避免這樣的問題，因為更多人的紅包大小會聚集在平均值附近，而且由于尾部更快的衰減，因此獲得特別大的紅包的概率也會相應減小，有助于增加公平性與參與的積極性。盡管具體截尾的范圍可能需要獲取更多的數據才有可能有一個準確的預測。
微信的金額什么時候算？
微信金額是拆的時候實時算出來，不是預先分配的，采用的是純內存計算，不需要預算空間存儲。
采取實時計算金額的考慮：預算需要占存儲，實時效率很高，預算才效率低。
實時性：為什么明明搶到紅包，點開后發現沒有？
2014年的紅包一點開就知道金額，分兩次操作，先搶到金額，然后再轉賬。
2015年的紅包的拆和搶是分離的，需要點兩次，因此會出現搶到紅包了，但點開后告知紅包已經被領完的狀況。進入到第一個頁面不代表搶到，只表示當時紅包還有。
分配：紅包里的金額怎么算？為什么出現各個紅包金額相差很大？
隨機，額度在0.01和(剩余平均值*2)之間。
例如：發100塊錢，總共10個紅包，那么平均值是10塊錢一個，那么發出來的紅包的額度在0.01元～20元之間波動。
當前面3個紅包總共被領了40塊錢時，剩下60塊錢，總共7個紅包，那么這7個紅包的額度在：0.01～(60/7*2)=17.14之間。
注意：這里的算法是每被搶一個后，剩下的會再次執行上面的這樣的算法
這樣算下去，會超過最開始的全部金額，因此到了最后面如果不夠這么算，那么會采取如下算法：保證剩余用戶能拿到最低1分錢即可。
如果前面的人手氣不好，那么后面的余額越多，紅包額度也就越多，因此實際概率一樣的。
紅包的設計
微信從財付通拉取金額數據郭萊，生成個數/紅包類型/金額放到redis集群里，app端將紅包ID的請求放入請求隊列中，如果發現超過紅包的個數，直接返回。根據紅包的裸祭(邏輯)處理成功得到令牌請求，則由財付通進行一致性調用，通過像比特幣一樣，兩邊保存交易記錄，交易后交給第三方服務審計，如果交易過程中出現不一致就強制回歸。
并發性處理：紅包如何計算被搶完？
cache會抵抗無效請求，將無效的請求過濾掉，實際進入到后臺的量不大。cache記錄紅包個數，原子操作進行個數遞減，到0表示被搶光。財付通按照20萬筆每秒入賬準備，但實際還不到8萬每秒。
如何保持8w每秒的寫入？
多主sharding，水平擴展機器。
占據容量多少？
一個紅包只占一條記錄，有效期只有幾天，因此不需要太多空間。
查詢詢紅包分配，壓力大不？
搶到紅包的人數和紅包都在一條cache記錄上，沒有太大的查詢壓力。
一個紅包一個隊列？
沒有隊列，一個紅包一條數據，數據上有一個計數器字段。
有沒有從數據上證明每個紅包的概率是不是均等？
不是絕對均等，就是一個簡單的拍腦袋算法。
拍腦袋算法，會不會出現兩個最佳？
會出現金額一樣的，但是手氣最佳只有一個，先搶到的那個最佳。
每領一個紅包就更新數據么？
每搶到一個紅包，就cas更新剩余金額和紅包個數。
紅包如何入庫入賬？
數據庫會累加已經領取的個數與金額，插入一條領取記錄。入賬則是后臺異步操作。
總結
以上是生活随笔為你收集整理的微信红包随机数字_微信红包的随机算法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： coreelec ssh访问被拒绝_Gi
- 下一篇： 深圳市罗湖区邮政编码是多少