實時性：為什麼明明搶到紅包，點開後發現沒有？
答：2023年的紅包一點開就知道金額，分兩次操作，先搶到金額，然後再轉賬。
2023年的紅包的拆和搶是分離的，需要點兩次，因此會出現搶到紅包了，但點開後告知紅包已經被領完的狀況。進入到第乙個頁面不代表搶到，只表示當時紅包還有。
分配：紅包裡的金額怎麼算？為什麼出現各個紅包金額相差很大？
答：隨機，額度在0.01和剩餘平均值2之間。
例如：發100塊錢，總共10個紅包，那麼平均值是10塊錢乙個，那麼發出來的紅包的額度在0.01元～20元之間波動。
當前面3個紅包總共被領了40塊錢時，剩下60塊錢，總共7個紅包，那麼這7個紅包的額度在：0.01～（60/72）=17.14之間。
注意：這裡的演算法是每被搶乙個後，剩下的會再次執行上面的這樣的演算法（tim老師也覺得上述演算法太複雜，不知基於什麼樣的考慮）。
這樣算下去，會超過最開始的全部金額，因此到了最後面如果不夠這麼算，那麼會採取如下演算法：保證剩餘使用者能拿到最低1分錢即可。
如果前面的人手氣不好，那麼後面的餘額越多，紅包額度也就越多，因此實際概率一樣的。
發性處理：紅包如何計算被搶完？
答：cache會抵抗無效請求，將無效的請求過濾掉，實際進入到後台的量不大。cache記錄紅包個數，原子操作進行個數遞減，到0表示被搶光。財付通按照20萬筆每秒入賬準備，但實際還不到8萬每秒。
通如何保持8w每秒的寫入？
答：多主sharding，水平擴充套件機器。
據容量多少？
答：乙個紅包只佔一條記錄，有效期只有幾天，因此不需要太多空間。
詢紅包分配，壓力大不？
答：搶到紅包的人數和紅包都在一條cache記錄上，沒有太大的查詢壓力。
乙個紅包乙個佇列？
答：沒有佇列，乙個紅包一條資料，資料上有乙個計數器字段。
有沒有從資料上證明每個紅包的概率是不是均等？
答：不是絕對均等，就是乙個簡單的拍腦袋演算法。
拍腦袋演算法，會不會出現兩個最佳？
答：會出現金額一樣的，但是手氣最佳只有乙個，先搶到的那個最佳。
每領乙個紅包就更新資料麼？
答：每搶到乙個紅包，就cas更新剩餘金額和紅包個數。
紅包如何入庫入賬？
資料庫會累加已經領取的個數與金額，插入一條領取記錄。入賬則是後台非同步操作。
入帳出錯怎麼辦？比如紅包個數沒了，但餘額還有？
答：最後會有乙個take all操作。另外還有乙個對賬來保障。
微信搶紅包演算法實現
只討論金額隨機的情況，需要滿足規則 所有人搶到金額之和要等於紅包總金額1.每個人至少搶到一分錢1.要保證所有人搶到金額的機率相等方案一 每個人點進來領，金額隨機，隨機的上限是當前剩餘的紅包金額。每次搶到的金額 隨機區間 0，剩餘紅包金額 分析 這樣做的缺陷是越早領越有優勢，因為每次搶到的金額 隨機區...
PHP實現微信紅包演算法和微信紅包的架構設計簡介
使用php發紅包，當我們輸入紅包數量和總金額後，php會根據這兩個值進行隨機分配每個金額，保證每個人都能領取到乙個紅包，每個紅包金額不等，就是要求紅包金額要有差異，所有紅包金額總額應該等於總金額。設定總金額為10元，有n個人隨機領取 n 1 第乙個 則紅包金額 x元 n 2 第二個 為保證第二個紅包...
微信開發之架構設計
同樣，使用者關注了我們後，我們可以不使用oauth2.0去進行網頁授權了，使用 獲取使用者基本資訊 介面同樣可以獲取使用者的基本資訊，這樣就不會有授權頁面出現，大大提高了使用者體驗。2 openid 3 accesstoken 4 session問題 sessionid其實是服務端識別使用者所屬se...