利用redis + lua解決搶紅包高并發的問題

搶紅包的場景有點像秒殺，但是要比秒殺簡單點。

因為秒殺通常要和庫存相關。而搶紅包則可以允許有些紅包沒有被搶到，因為發紅包的人不會有損失，沒搶完的錢再退回給發紅包的人即可。

另外像小米這樣的搶購也要比淘寶的要簡單，也是因為像小米這樣是一個公司的，如果有少量沒有搶到，則下次再搶，人工修複下資料是很簡單的事。而像淘寶這麼多商品，要是每一個都存在着修複資料的風險，那如果出故障了則很麻煩。

淘寶的專家丁奇有個文章有寫到淘寶是如何應對秒殺的：《秒殺場景下mysql的低效–原因和改進》

http://blog.nosqlfan.com/html/4209.html

下面介紹一種基于redis的搶紅包方案。

把原始的紅包稱為大紅包，拆分後的紅包稱為小紅包。

1.小紅包預先生成，插到資料庫裡，紅包對應的使用者id是null。生成算法見另一篇blog：http://blog.csdn.net/hengyunabc/article/details/19177877

2.每個大紅包對應兩個redis隊列，一個是未消費紅包隊列，另一個是已消費紅包隊列。開始時，把未搶的小紅包全放到未消費紅包隊列裡。

未消費紅包隊列裡是json字元串，如{userid:'789', money:'300'}。

3.在redis中用一個map來過濾已搶到紅包的使用者。

4.搶紅包時，先判斷使用者是否搶過紅包，如果沒有，則從未消費紅包隊列中取出一個小紅包，再push到另一個已消費隊列中，最後把使用者id放入去重的map中。

5.用一個單線程批量把已消費隊列裡的紅包取出來，再批量update紅包的使用者id到資料庫裡。

上面的流程是很清楚的，但是在第4步時，如果是使用者快速點了兩次，或者開了兩個浏覽器來搶紅包，會不會有可能使用者搶到了兩個紅包？

為了解決這個問題，采用了lua腳本方式，讓第4步整個過程是原子性地執行。

下面是在redis上執行的lua腳本：

下面是測試代碼：

測試結果20個線程，每秒可以搶2.5萬個，足以應付絕大部分的搶紅包場景。

如果是真的應付不了，拆分到幾個redis叢集裡，或者改為批量搶紅包，也足夠應付。

redis的搶紅包方案，雖然在極端情況下（即redis挂掉）會丢失一秒的資料，但是卻是一個擴充性很強，足以應付高并發的搶紅包方案。