① 微信紅包的隨機演算法是怎樣實現的
1. 紅包分配演算法概述:
當有100元需要由10個人平均分配時,每個人理論上將獲得10元。隨後,系統開始按照特定的隨機規則分配紅包。
2. 紅包第一份分配:
系統將從0元到10元之間隨機選擇一個數額作為第一份紅包的金額,設為x1。
3. 紅包後續份數分配:
對於剩下的金額(100-x1),系統將從這個剩餘金額除以剩餘份數(10-1)的結果之間隨機選擇一個數額作為下一份紅包的金額,設為x2。此過程重復,直至所有份數分配完畢。
4. 用戶領取紅包的規則:
當一個用戶來領取紅包時,系統將從0到9之間隨機選擇一個數字。這個數字對應領取第幾份紅包。系統將這個數字存入一個列表(list)中。
5. 避免重復領取紅包:
如果後續用戶隨機到的數字與之前相同,則在列表中對應的數字加1。如果遇到重復的數字再次加1,直至列表滿員,所有的紅包被領取。
希望以上解釋能幫助理解微信紅包的隨機分配演算法,如果你滿意,請採納。
② 微信紅包的隨機演算法是怎樣實現的
當有人在微信群里發了一個 N 人的紅包、總金額 M 元,後台大概的技術邏輯如下。
發紅包後台操作:
1)在資料庫中增加一條紅包記錄,存儲到CKV,設置過期時間;
2)在Cache(可能是騰訊內部kv資料庫,基於內存,有落地,有內核態網路處理模塊,以內核模塊形式提供服務))中增加一條記錄,存儲搶紅包的人數N。
搶紅包後台操作:
1)搶紅包分為搶和拆:搶操作在Cache層完成,通過原子減操作進行紅包數遞減,到0就說明搶光了,最終實際進入後台拆操作的量不大,通過操作的分離將無效請求直接擋在Cache層外面。這里的原子減操作並不是真正意義上的原子減操作,是其Cache層提供的CAS,通過比較版本號不斷嘗試,存在一定程度上的沖突,沖突的用戶會放行,讓其進入下一步拆的操作,這也解釋了為啥有用戶搶到了拆開發現領完了的情況。
2)拆紅包在資料庫完成:通過資料庫的事務操作累加已經領取的個數和金額,插入一條領取流水,入賬為非同步操作,這也解釋了為啥在春節期間紅包領取後在余額中看不到。拆的時候會實時計算金額,其金額為1分到剩餘平均值2倍之間隨機數,一個總金額為M元的紅包,最大的紅包為 M * 2 /N(且不會超過M),當拆了紅包後會更新剩餘金額和個數。財付通按20萬筆每秒入賬准備,實際只到8萬每秒。