微信紅包分配演算法

A. 微信紅包的隨機演算法是怎樣的

1）紅包大小服從截尾正態分布，其好處是減少抽取紅包大小分布的方差，讓更多的人抽取的紅包在均值附近，同時仍給一小部分人抽取大紅包的機會，總體來說增加了紅包抽取人的積極性和游戲的公平性；
2）抽取紅包大小與抽取紅包先後無相關性。一種可能的紅包產生機制是：當發紅包者<准備紅包>的時候，程序自動依照截尾分布產生了相應大小，相應個數的紅包，然後隨機發給抽取紅包的人。同樣，這樣的一個隨機過程有助於增加游戲的公平性，也減少了紅包抽取人投機操作。

錢包錢數滿足截尾正態隨機數分布。大致為在截尾正態分布中取隨機數，並用其求和數除以總價值，獲得修正因子，再用修正因子乘上所有的隨機數，得到紅包價值。

這種分布意味著：低於平均值的紅包多，但是離平均值不遠；高於平均值的紅包少，但是遠大於平均值的紅包

B. 微信中發紅包時怎麼平均分配

微信紅包有兩種，一種就是拼手氣紅包，還有一種就是普通紅包，普通紅包就屬於平均分配！

C. 微信群裡面發紅包，群里成員領到的紅包金額是怎麼計算的，是隨機的還是怎麼來的

摘要 這個的話主要是看你發的是什麼紅包的。假如說你發的一個紅包設置為可以6個人搶。這樣的話裡面的錢就會被隨機分配的，一般的話都是隨機分配。

D. 微信紅包金額怎麼分配

微信紅包分兩種：
1、單獨發給一個人的，紅包都歸個人；
2、紅包發到群里的，會隨機分配；
但根據個人發紅包的經驗，頭兩個和倒數四到五個，通常拿不到最大的紅包。
最容易拿到大紅包的，是倒數第一第二，通常都是手氣最佳。
根據個人的經驗。

E. 微信紅包怎麼平均分配

摘要 1.微信紅包要平均分，只需要發普通紅包即可。

F. 微信紅包如何等分金額

發紅包時左上角有個選項1是拼手氣紅包，2是普通紅包，3是專屬紅包，
選擇普通紅包，發多少個。每個多少錢，按照選項操作就行。
希望能幫助到你

G. 微信紅包怎麼分配金額大小

微信紅包的分配大小是系統自動分配的。沒有辦法進行人工的參與，網上買的一些。可以保證你搶到大紅包的軟體都是騙人的，不要相信

H. 隨機紅包金額如何決定的

從工程角度來說，紅包分配演算法需要簡單粗暴的實現。

有些人的演算法過於復雜，第幾個人領取都要面面俱到的計算，考慮因素太多，工程實現上真的沒必要。
其實只需要按照如下框架即可：

1. 發紅包時，按照設計的快速隨機演算法，將紅包分好若干份。

2. 按照設計的評估演算法，對得到的紅包分配進行校驗。

3. 如果校驗不通過，如貧富差距過大，則重復隨機分配。

4. 如果若干次重復，如5次，則停止重復，就按照當前分配。

5. 再有用戶請求紅包，直接隊列化請求，再從紅包序列中取出對應編號紅包。

上述方案的優勢是：
1. 只需「一次」計算。

隨機演算法選擇簡單粗暴的即可，系統按照校驗策略對其評價，不滿足則有限次重復，直到滿足或次數太多為止。

2. 此後就只有讀取。

後續操作完全是讀取緩存，無需密集計算。

那麼是不是還有更簡單粗暴的方案呢?還是有的，那就是偽隨機序列查表法。

百萬千萬級別的紅包請求，如果每次都按照真隨機來計算，仍然會有不小的計算壓力。

索性預先計算得到若干偽隨機分配方案，調用時只需要隨機選擇一個即可。
舉例來說，有人的紅包是10元分配給5人，系統預先存有多種分配方案，如1，1，2，3，3，或1，1，2，2，4，請求時隨機選取一個方案即可。

當然，各種組合未必能窮盡，但是只需要讓用戶在有限次操作中覺得這是隨機就夠了。
(8)微信紅包分配演算法擴展閱讀
微信紅包是騰訊旗下產品微信於2014年1月27日推出的一款應用，功能上可以實現發「紅包」、查收發記錄和提現。

2014年4月14日，「安卓手機用戶只要用微信掃描身邊出現的紅色二維碼，通過騰訊應用寶成功安裝其他應用軟體，即可領取微信紅包。

2019年2月10日，微信官方發布2019年春節數據報告，除夕到初五，8.23億人次收發微信紅包。
設計簡單

在「微信紅包」這個功能的設計上，遵循了簡單的原則。發送方通過「新年紅包」公眾號，選擇發送紅包的數量和金額，以及祝福的話語，通過「微信支付」進行支付，就可以發送給好友；接收方則在打開後獲得相應收益，只需要將儲蓄卡與微信關聯，就可以在一個工作日後提現。2014年1月27日前，用戶在搶紅包之前，要先寫上祝福，然後才可以搶。在這之後，已經改為先搶紅包再發送祝福的過程。

I. 微信紅包的隨機演算法是怎樣實現的

當有人在微信群里發了一個 N 人的紅包、總金額 M 元，後台大概的技術邏輯如下。

發紅包後台操作：

1）在資料庫中增加一條紅包記錄，存儲到CKV，設置過期時間；

2）在Cache（可能是騰訊內部kv資料庫，基於內存，有落地，有內核態網路處理模塊，以內核模塊形式提供服務））中增加一條記錄，存儲搶紅包的人數N。

搶紅包後台操作：

1）搶紅包分為搶和拆：搶操作在Cache層完成，通過原子減操作進行紅包數遞減，到0就說明搶光了，最終實際進入後台拆操作的量不大，通過操作的分離將無效請求直接擋在Cache層外面。這里的原子減操作並不是真正意義上的原子減操作，是其Cache層提供的CAS，通過比較版本號不斷嘗試，存在一定程度上的沖突，沖突的用戶會放行，讓其進入下一步拆的操作，這也解釋了為啥有用戶搶到了拆開發現領完了的情況。

2）拆紅包在資料庫完成：通過資料庫的事務操作累加已經領取的個數和金額，插入一條領取流水，入賬為非同步操作，這也解釋了為啥在春節期間紅包領取後在余額中看不到。拆的時候會實時計算金額，其金額為1分到剩餘平均值2倍之間隨機數，一個總金額為M元的紅包，最大的紅包為 M * 2 /N（且不會超過M），當拆了紅包後會更新剩餘金額和個數。財付通按20萬筆每秒入賬准備，實際只到8萬每秒。