計算：微信金額是拆的時候實時算出來，不是預先分配的，採用的是純記憶體計算，不需要預算空間存儲。採取實時計算金額的考慮：預算需要占存儲，實時效率很高，預算才效率低。2014年微信紅包使用資料庫硬抗整個流量，2015年使用cache抗流量。 實時性：為什麼明明搶到紅包，點開後發現沒有，2014年的紅包一點
計算：微信金額是拆的時候實時算出來，不是預先分配的，採用的是純記憶體計算，不需要預算空間存儲。採取實時計算金額的考慮：預算需要占存儲，實時效率很高，預算才效率低。2014年微信紅包使用資料庫硬抗整個流量，2015年使用cache抗流量。
實時性：為什麼明明搶到紅包，點開後發現沒有，2014年的紅包一點開就知道金額，分兩次操作，先搶到金額，然後再轉賬。2015年的紅包的拆和搶是分離的，需要點兩次，因此會出現搶到紅包了，但點開後告知紅包已經被領完的狀況。進入到第一個頁面不代表搶到，只表示當時紅包還有。
分配：紅包里的金額怎麼算？為什麼出現各個紅包金額相差很大？答：隨機，額度在0.01和(剩餘平均值*2)之間。例如：發100塊錢，總共10個紅包，那麼平均值是10塊錢一個，那麼發出來的紅包的額度在0.01元～20元之間波動。當前面3個紅包總共被領了40塊錢時，剩下60塊錢，總共7個紅包，那麼這7個紅包的額度在：0.01～（60/7*2）=17.14之間。註意：這裡的演算法是每被搶一個後，剩下的會再次執行上面的這樣的演算法（Tim老師也覺得上述演算法太複雜，不知基於什麼樣的考慮）。這樣算下去，會超過最開始的全部金額，因此到了最後面如果不夠這麼算，那麼會採取如下演算法：保證剩餘用戶能拿到最低1分錢即可。如果前面的人手氣不好，那麼後面的餘額越多，紅包額度也就越多，因此實際概率一樣的。
紅包的設計：微信從財付通拉取金額數據過來，生成個數/紅包類型/金額放到redis集群里，app端將紅包ID的請求放入請求隊列中，如果發現超過紅包的個數，直接返回。根據紅包的裸祭處理成功得到令牌請求，則由財付通進行一致性調用，通過像比特幣一樣，兩邊保存交易記錄，交易後交給第三方服務審計，如果交易過程中出現不一致就強制回歸。
import java.util.Random;
/*
* floor 向下取整
* round 四捨五入
* ceil 向上取整
*/
public class LuckyMoney {
private static final double BASEMONEY = 0.01;
public static void main(String[] args) {
int totalNum = 3;
double totalMoney = 1;
for (int i = 0; i < 100; i++)
dispatch(totalNum, totalMoney);
}
private static void dispatch(int totalNum, double totalMoney) {
try {
verifyData(totalNum, totalMoney);
double sendMoney = 0.0;
RedPacket redPacket = new RedPacket(totalNum, totalMoney);
while (redPacket.num >= 1) {
Random r = new Random();
double min = BASEMONEY;
double max = (redPacket.money / redPacket.num) * 2;
double money = r.nextFloat() * max;
if (redPacket.num == 1) {
money = (sendMoney + redPacket.money == 1)
? redPacket.money
: (redPacket.money + 0.01);
}
money = (money <= min ? min : Math.floor(money * 100) / 100);
sendMoney += money;
System.out.println("第" + (totalNum + 1 - redPacket.num)
+ "個紅包金額：" + money + ", 剩餘紅包金額："
+ (Math.ceil((totalMoney - sendMoney) * 100) / 100));
redPacket.num--;
redPacket.money = Math.floor((redPacket.money - money) * 100) / 100;
}
} catch (Exception e) {
e.printStackTrace();
}
}
private static void verifyData(int totalNum, double totalMoney)
throws Exception {
if (totalMoney < (totalNum * BASEMONEY)) {
System.err.println("錢太少，不夠分");
throw new Exception("Error");
}
}
}
class RedPacket {
int num;
double money;
public RedPacket(int num, double money) {
this.num = num;
this.money = money;
}
}
該演算法會出現金額一樣的，但是手氣最佳只有一個，先搶到的那個最佳。
併發性處理：紅包如何計算被搶完？cache會抵抗無效請求，將無效的請求過濾掉，實際進入到後臺的量不大。cache記錄紅包個數，原子操作進行個數遞減，到0表示被搶光。財付通按照20萬筆每秒入賬準備，但實際還不到8萬每秒。財富通如何保持8w每秒的寫入？多主sharding，水平擴展機器。數據容量多少？一個紅包只占一條記錄，有效期只有幾天，因此不需要太多空間。查詢紅包分配，壓力大不？搶到紅包的人數和紅包都在一條cache記錄上，沒有太大的查詢壓力。一個紅包一個隊列？沒有隊列，一個紅包一條數據，數據上有一個計數器欄位。
拆包：為了保證每次操作的原子性，拆包過程中使用了CAS，確保每次只有一個併發用戶拆包成功。拆包CAS失敗的用戶可以由系統自動進行重試。但也有可能在重試過程中被別的用戶搶得先機而空手而歸，因此嚴格意義拆包的調用也未能保證用戶先到先得。
預分配策略和實時計算策略：微信紅包為了減少存儲，每次進行了一個理解稍複雜的實時計算。對比大部分架構師想到的預分配金額的做法，預先分配金額需要將金額保存在一個記憶體隊列中，如果紅包的份額較多，則需要較大的存儲空間。而微信紅包僅保存 count:balance這樣2個數字。count指還剩幾個人可以搶，balance只還剩下的金額。但是預分配金額也並不是非得需要額外存儲。比如利用隨機演算法，在種子相同的情況下，隨機數實際上返回的隨機序列也是固定的。因此預分配金額也只需要額外存儲一個種子，或利用一些紅包id做加密變換做seed達到零存儲。而在發放紅包時候，無需進行CAS操作，而只需要對剩餘紅包count做一個DECR操作。當count<0時，表示紅包被拆包搶完。由於DECR是原子操作，無需加鎖，用簡單的方法達到了先拆包先得，原理上不存在早拆包但由於併發衝突失敗而搶不到紅包的情況。每個人分配的金額是：total * random(n) / random_total，不需要重覆計算。random(1)..random(n)不需要保存，因為對於給定的seed，random(1)到random(n)返回是固定的。
參考文獻：
[1] https://www.zhihu.com/question/22625187
[2] https://www.zybuluo.com/yulin718/note/93148
