一、首先來一個搶紅包的案例：
搶紅包的場景有點像秒殺，但是要比秒殺簡單點。
因為秒殺通常要和庫存相關。而搶紅包則可以允許有些紅包沒有被搶到，因為發紅包的人不會有損失，沒搶完的錢再退回給發紅包的人即可。
另外像小米這樣的搶購也要比淘寶的要簡單，也是因為像小米這樣是一個公司的，如果有少量沒有搶到，則下次再搶，人工修復下數據是很簡單的事。而像淘寶這么多商品，要是每一個都存在着修復數據的風險，那如果出故障了則很麻煩。
基於redis的搶紅包方案
下面介紹一種基於redis的搶紅包方案。
把原始的紅包稱為大紅包，拆分后的紅包稱為小紅包。
1.小紅包預先生成，插到數據庫里，紅包對應的用戶ID是null。生成算法見另一篇blog：http://blog.csdn.net/hengyunabc/article/details/19177877
2.每個大紅包對應兩個redis隊列，一個是未消費紅包隊列，另一個是已消費紅包隊列。開始時，把未搶的小紅包全放到未消費紅包隊列里。
已消費紅包隊列里是json字符串，如{userId:'xxx', money:'yyy'}。
3.在redis中用一個map來過濾已搶到紅包的用戶。
4.搶紅包時，先判斷用戶是否搶過紅包，如果沒有，則從未消費紅包隊列中取出一個小紅包，再push到另一個已消費隊列中，最后把用戶ID放入map中（已經添加前已經判斷過有沒有添加，所以是去重的map）。
5.用一個單線程批量把已消費隊列里的紅包取出來，再批量update紅包的用戶ID到數據庫里。
上面的流程是很清楚的，但是在第4步時，如果是用戶快速點了兩次，或者開了兩個瀏覽器來搶紅包，會不會有可能用戶搶到了兩個紅包？
為了解決這個問題，采用了lua腳本方式，讓第4步整個過程是原子性地執行。
下面是在redis上執行的Lua腳本：
-- 函數：嘗試獲得紅包，如果成功，則返回json字符串，如果不成功，則返回空
-- 參數：紅包隊列名， 已消費的隊列名，去重的Map名，用戶ID
-- 返回值：nil 或者 json字符串，包含用戶ID：userId，紅包ID：id，紅包金額：money
-- 如果用戶已搶過紅包，則返回nil
if redis.call('hexists', KEYS[3], KEYS[4]) ~= 0 then
return nil
else
-- 先取出一個小紅包
local hongBao = redis.call('rpop', KEYS[1]);
if hongBao then
local x = cjson.decode(hongBao);
-- 加入用戶ID信息
x['userId'] = KEYS[4];
local re = cjson.encode(x);
-- 把用戶ID放到去重的set里
redis.call('hset', KEYS[3], KEYS[4], KEYS[4]);
-- 把紅包放到已消費隊列里
redis.call('lpush', KEYS[2], re);
return re;
end
end
return nil
下面是測試代碼：
public class TestEval {
static String host = "localhost";
static int honBaoCount = 1_0_0000;
static int threadCount = 20;
static String hongBaoList = "hongBaoList";
static String hongBaoConsumedList = "hongBaoConsumedList";
static String hongBaoConsumedMap = "hongBaoConsumedMap";
static Random random = new Random();
// -- 函數：嘗試獲得紅包，如果成功，則返回json字符串，如果不成功，則返回空
// -- 參數：紅包隊列名， 已消費的隊列名，去重的Map名，用戶ID
// -- 返回值：nil 或者 json字符串，包含用戶ID：userId，紅包ID：id，紅包金額：money
static String tryGetHongBaoScript =
// "local bConsumed = redis.call('hexists', KEYS[3], KEYS[4]);\n"
// + "print('bConsumed:' ,bConsumed);\n"
"if redis.call('hexists', KEYS[3], KEYS[4]) ~= 0 then\n"
+ "return nil\n"
+ "else\n"
+ "local hongBao = redis.call('rpop', KEYS[1]);\n"
// + "print('hongBao:', hongBao);\n"
+ "if hongBao then\n"
+ "local x = cjson.decode(hongBao);\n"
+ "x['userId'] = KEYS[4];\n"
+ "local re = cjson.encode(x);\n"
+ "redis.call('hset', KEYS[3], KEYS[4], KEYS[4]);\n"
+ "redis.call('lpush', KEYS[2], re);\n"
+ "return re;\n"
+ "end\n"
+ "end\n"
+ "return nil";
static StopWatch watch = new StopWatch();
public static void main(String[] args) throws InterruptedException {
// testEval();
generateTestData();
testTryGetHongBao();
}
static public void generateTestData() throws InterruptedException {
Jedis jedis = new Jedis(host);
jedis.flushAll();
final CountDownLatch latch = new CountDownLatch(threadCount);
for(int i = 0; i < threadCount; ++i) {
final int temp = i;
Thread thread = new Thread() {
public void run() {
Jedis jedis = new Jedis(host);
int per = honBaoCount/threadCount;
JSONObject object = new JSONObject();
for(int j = temp * per; j < (temp+1) * per; j++) {
object.put("id", j);
object.put("money", j);
jedis.lpush(hongBaoList, object.toJSONString());
}
latch.countDown();
}
};
thread.start();
}
latch.await();
}
static public void testTryGetHongBao() throws InterruptedException {
final CountDownLatch latch = new CountDownLatch(threadCount);
System.err.println("start:" + System.currentTimeMillis()/1000);
watch.start();
for(int i = 0; i < threadCount; ++i) {
final int temp = i;
Thread thread = new Thread() {
public void run() {
Jedis jedis = new Jedis(host);
String sha = jedis.scriptLoad(tryGetHongBaoScript);
int j = honBaoCount/threadCount * temp;
while(true) {
Object object = jedis.eval(tryGetHongBaoScript, 4, hongBaoList, hongBaoConsumedList, hongBaoConsumedMap, "" + j);
j++;
if (object != null) {
// System.out.println("get hongBao:" + object);
}else {
//已經取完了
if(jedis.llen(hongBaoList) == 0)
break;
}
}
latch.countDown();
}
};
thread.start();
}
latch.await();
watch.stop();
System.err.println("time:" + watch.getTotalTimeSeconds());
System.err.println("speed:" + honBaoCount/watch.getTotalTimeSeconds());
System.err.println("end:" + System.currentTimeMillis()/1000);
}
}
測試結果20個線程，每秒可以搶2.5萬個，足以應付絕大部分的搶紅包場景。
如果是真的應付不了，拆分到幾個redis集群里，或者改為批量搶紅包，也足夠應付。
redis的搶紅包方案，雖然在極端情況下（即redis掛掉）會丟失一秒的數據，但是卻是一個擴展性很強，足以應付高並發的搶紅包方案。
二、秒殺場景案例分析：
秒殺系統的特點
- 新品上市 價格低廉
- 市場造勢 大幅推廣
- 指定時間開售
- 瞬時售空
- 讀多寫少
秒殺系統難點
- 高並發、負載壓力大
- 競爭資源是有限的
- 對其他業務的影響
- 提防“黃牛黨”
秒殺系統應用場景
- 商品搶購
- 群紅包
- 優惠卷領取
- 搶火車票
- 在線預約
技術維度對秒殺系統的分析 —— 架構原則
技術維度對秒殺系統的分析 —— 優化技術
業務維度對秒殺系統的分析
修改庫存放在訂單支付的前面位置 體現了企業的良心
秒殺沒搶到的話 訂單30分鍾未支付會取消訂單 釋放庫存 可以撿漏
核心業務基於DB的實現
場景描述
業務描述：有50台蘋果7手機，模擬200個用戶同時請求購買，每個人都購買N台手機
實現原理：基於數據庫的樂觀鎖 表t_goods_info
update t_goods_info set amout = amout - #{buys} where code = #{code} and amout - #{buys} >=0
優點:實現簡單, 最可靠
缺點: 並發量小 300 or 700
核心業務基於cache的實現(memcache)
場景描述
業務描述：有50台蘋果7手機，模擬200個用戶同時請求購買，每個人都購買N台手機
實現原理：基於緩存的樂觀鎖 。基於memcache的decr，decr是原子的。
decr是有毒的
Decr的返回值有只有三種情況，
“>0”“=0”(減數大於被減數) “=-1”(鍵值不存在)
10 – 100 =0(這里有毒)
Memcached是不支持事務的
操作序列不是原子性的
解決
輕量級的鎖機制CAS機制
解釋：Check and set ,即保存之前進行版本檢查，memcache 1.2.4新增的特性。
- gets： 獲取item，並獲取版本號
- cas：更新item，並上傳獲取item時的版本號，版本號與服務器一致才能更新成功
算法如下: 
核心代碼:
@Override
public Boolean updateGoodsAmount(String code, int buys) { MemcachedItem item = client.gets(code); if(Integer.valueOf(item.getValue().toString().trim()) < buys ){ return false; }else{ if(client.cas(code, String.valueOf(Integer.valueOf(item.getValue().toString().trim())-buys), item.casUnique)){ return true; }else{ return updateGoodsAmount(code,buys); } } }Redis 與 memcached 的秒殺之爭
