利用redis + lua解決搶紅包高并發的問題
搶紅包的需求分析
搶紅包的場景有點像秒殺,但是要比秒殺簡單點。
因為秒殺通常要和庫存相關。而搶紅包則可以允許有些紅包沒有被搶到,因為發紅包的人不會有損失,沒搶完的錢再退回給發紅包的人即可。
另外像小米這樣的搶購也要比淘寶的要簡單,也是因為像小米這樣是一個公司的,如果有少量沒有搶到,則下次再搶,人工修復下數據是很簡單的事。而像淘寶這么多商品,要是每一個都存在著修復數據的風險,那如果出故障了則很麻煩。
淘寶的專家丁奇有個文章有寫到淘寶是如何應對秒殺的:《秒殺場景下MySQL的低效–原因和改進》
http://blog.nosqlfan.com/html/4209.html
基于redis的搶紅包方案
下面介紹一種基于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掛掉)會丟失一秒的數據,但是卻是一個擴展性很強,足以應付高并發的搶紅包方案。
來自:http://blog.csdn.net/hengyunabc/article/details/19433779