答：微信金額是拆的時候?qū)崟r算出來，不是預(yù)先分配的，采用的是純內(nèi)存計算，不需要預(yù)算空間存儲。
采取實(shí)時計算金額的考慮：預(yù)算需要占存儲，實(shí)時效率很高，預(yù)算才效率低。

答：2014年的紅包一點(diǎn)開就知道金額，分兩次操作，先搶到金額，然后再轉(zhuǎn)賬。
2015年的紅包的拆和搶是分離的，需要點(diǎn)兩次，因此會出現(xiàn)搶到紅包了，但點(diǎn)開后告知紅包已經(jīng)被領(lǐng)完的狀況。進(jìn)入到第一個頁面不代表搶到，只表示當(dāng)時紅包還有。

答：隨機(jī)，額度在0.01和(剩余平均值*2)之間。
例如：發(fā)100塊錢，總共10個紅包，那么平均值是10塊錢一個，那么發(fā)出來的紅包的額度在0.01元～20元之間波動。
當(dāng)前面3個紅包總共被領(lǐng)了40塊錢時，剩下60塊錢，總共7個紅包，那么這7個紅包的額度在：0.01～（60/7*2）=17.14之間。
注意：這里的算法是每被搶一個后，剩下的會再次執(zhí)行上面的這樣的算法（Tim老師也覺得上述算法太復(fù)雜，不知基于什么樣的考慮）。

這樣算下去，會超過最開始的全部金額，因此到了最后面如果不夠這么算，那么會采取如下算法：保證剩余用戶能拿到最低1分錢即可。

如果前面的人手氣不好，那么后面的余額越多，紅包額度也就越多，因此實(shí)際概率一樣的。

答：微信從財付通拉取金額數(shù)據(jù)過來，生成個數(shù)/紅包類型/金額放到redis集群里，app端將紅包ID的請求放入請求隊(duì)列中，如果發(fā)現(xiàn)超過紅包的個數(shù)，直接返回。根據(jù)紅包的邏輯處理成功得到令牌請求，則由財付通進(jìn)行一致性調(diào)用，通過像比特幣一樣，兩邊保存交易記錄，交易后交給第三方服務(wù)審計，如果交易過程中出現(xiàn)不一致就強(qiáng)制回歸。

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

答：多主sharding，水平擴(kuò)展機(jī)器。

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

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

答：沒有隊(duì)列，一個紅包一條數(shù)據(jù)，數(shù)據(jù)上有一個計數(shù)器字段。

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

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

答：每搶到一個紅包，就cas更新剩余金額和紅包個數(shù)。

數(shù)據(jù)庫會累加已經(jīng)領(lǐng)取的個數(shù)與金額，插入一條領(lǐng)取記錄。入賬則是后臺異步操作。

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