SpringBoot + Redis:模擬 10w 人的秒殺搶單!
原文連結:https://mp.weixin.qq.com/s/Znrc9-z6xhlqCjWvw08_bg
本篇內容主要講解的是redis分散式鎖,這個在各大廠面試幾乎都是必備的,下面結合模擬搶單的場景來使用她;本篇不涉及到的redis環境搭建,快速搭建個人測試環境,這裡建議使用docker;本篇內容節點如下:
Jedis的nx生成鎖
- 如何刪除鎖
- 模擬搶單動作(10w個人開搶)
- jedis的nx生成鎖
對於java中想操作redis,好的方式是使用jedis,首先pom中引入依賴:
<dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> </dependency>
對於分散式鎖的生成通常需要注意如下幾個方面:
建立鎖的策略: redis的普通key一般都允許覆蓋,A使用者set某個key後,B在set相同的key時同樣能成功,如果是鎖場景,那就無法知道到底是哪個使用者set成功的;這裡jedis的setnx方式為我們解決了這個問題,簡單原理是:當A使用者先set成功了,那B使用者set的時候就返回失敗,滿足了某個時間點只允許一個使用者拿到鎖。
鎖過期時間: 某個搶購場景時候,如果沒有過期的概念,當A使用者生成了鎖,但是後面的流程被阻塞了一直無法釋放鎖,那其他使用者此時獲取鎖就會一直失敗,無法完成搶購的活動;當然正常情況一般都不會阻塞,A使用者流程會正常釋放鎖;過期時間只是為了更有保障。
下面來上段setnx操作的程式碼:
public boolean setnx(String key, String val) { Jedis jedis = null; try { jedis = jedisPool.getResource(); if (jedis == null) { return false; } return jedis.set(key, val, "NX", "PX", 1000 * 60). equalsIgnoreCase("ok"); } catch (Exception ex) { } finally { if (jedis != null) { jedis.close(); } } return false; }
這裡注意點在於jedis的set方法,其引數的說明如:
- NX:是否存在key,存在就不set成功
- PX:key過期時間單位設定為毫秒(EX:單位秒)
setnx如果失敗直接封裝返回false即可,下面我們通過一個get方式的api來呼叫下這個setnx方法:
@GetMapping("/setnx/{key}/{val}") public boolean setnx(@PathVariable String key, @PathVariable String val) { return jedisCom.setnx(key, val); }
訪問如下測試url,正常來說第一次返回了true,第二次返回了false,由於第二次請求的時候redis的key已存在,所以無法set成功
由上圖能夠看到只有一次set成功,並key具有一個有效時間,此時已到達了分散式鎖的條件。
如何刪除鎖
上面是建立鎖,同樣的具有有效時間,但是我們不能完全依賴這個有效時間,場景如:有效時間設定1分鐘,本身使用者A獲取鎖後,沒遇到什麼特殊情況正常生成了搶購訂單後,此時其他使用者應該能正常下單了才對,但是由於有個1分鐘後鎖才能自動釋放,那其他使用者在這1分鐘無法正常下單(因為鎖還是A使用者的),因此我們需要A使用者操作完後,主動去解鎖:
public int delnx(String key, String val) { Jedis jedis = null; try { jedis = jedisPool.getResource(); if (jedis == null) { return 0; } //if redis.call('get','orderkey')=='1111' then return redis.call('del','orderkey') else return 0 end StringBuilder sbScript = new StringBuilder(); sbScript.append("if redis.call('get','").append(key).append("')").append("=='").append(val).append("'"). append(" then "). append(" return redis.call('del','").append(key).append("')"). append(" else "). append(" return 0"). append(" end"); return Integer.valueOf(jedis.eval(sbScript.toString()).toString()); } catch (Exception ex) { } finally { if (jedis != null) { jedis.close(); } } return 0; }
這裡也使用了jedis方式,直接執行lua指令碼:根據val判斷其是否存在,如果存在就del;
其實個人認為通過jedis的get方式獲取val後,然後再比較value是否是當前持有鎖的使用者,如果是那最後再刪除,效果其實相當;只不過直接通過eval執行指令碼,這樣避免多一次操作了redis而已,縮短了原子操作的間隔。(如有不同見解請留言探討);同樣這裡建立個get方式的api來測試:
@GetMapping("/delnx/{key}/{val}") public int delnx(@PathVariable String key, @PathVariable String val) { return jedisCom.delnx(key, val); }
注意的是delnx時,需要傳遞建立鎖時的value,因為通過et的value與delnx的value來判斷是否是持有鎖的操作請求,只有value一樣才允許del;
模擬搶單動作(10w個人開搶)
有了上面對分散式鎖的粗略基礎,我們模擬下10w人搶單的場景,其實就是一個併發操作請求而已,由於環境有限,只能如此測試;如下初始化10w個使用者,並初始化庫存,商品等資訊,如下程式碼:
//總庫存 private long nKuCuen = 0; //商品key名字 private String shangpingKey = "computer_key"; //獲取鎖的超時時間 秒 private int timeout = 30 * 1000; @GetMapping("/qiangdan") public List<String> qiangdan() { //搶到商品的使用者 List<String> shopUsers = new ArrayList<>(); //構造很多使用者 List<String> users = new ArrayList<>(); IntStream.range(0, 100000).parallel().forEach(b -> { users.add("神牛-" + b); }); //初始化庫存 nKuCuen = 10; //模擬開搶 users.parallelStream().forEach(b -> { String shopUser = qiang(b); if (!StringUtils.isEmpty(shopUser)) { shopUsers.add(shopUser); } }); return shopUsers; }
有了上面10w個不同使用者,我們設定商品只有10個庫存,然後通過並行流的方式來模擬搶購,如下搶購的實現:
/** * 模擬搶單動作 * * @param b * @return */ private String qiang(String b) { //使用者開搶時間 long startTime = System.currentTimeMillis(); //未搶到的情況下,30秒內繼續獲取鎖 while ((startTime + timeout) >= System.currentTimeMillis()) { //商品是否剩餘 if (nKuCuen <= 0) { break; } if (jedisCom.setnx(shangpingKey, b)) { //使用者b拿到鎖 logger.info("使用者{}拿到鎖...", b); try { //商品是否剩餘 if (nKuCuen <= 0) { break; } //模擬生成訂單耗時操作,方便檢視:神牛-50 多次獲取鎖記錄 try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); } //搶購成功,商品遞減,記錄使用者 nKuCuen -= 1; //搶單成功跳出 logger.info("使用者{}搶單成功跳出...所剩庫存:{}", b, nKuCuen); return b + "搶單成功,所剩庫存:" + nKuCuen; } finally { logger.info("使用者{}釋放鎖...", b); //釋放鎖 jedisCom.delnx(shangpingKey, b); } } else { //使用者b沒拿到鎖,在超時範圍內繼續請求鎖,不需要處理 // if (b.equals("神牛-50") || b.equals("神牛-69")) { // logger.info("使用者{}等待獲取鎖...", b); // } } } return ""; }
這裡實現的邏輯是:
1、parallelStream():並行流模擬多使用者搶購
2、(startTime + timeout) >= System.currentTimeMillis():判斷未搶成功的使用者,timeout秒內繼續獲取鎖
3、獲取鎖前和後都判斷庫存是否還足夠
4、jedisCom.setnx(shangpingKey, b):使用者獲取搶購鎖
5、獲取鎖後並下單成功,最後釋放鎖:jedisCom.delnx(shangpingKey, b)
再來看下記錄的日誌結果:
最終返回搶購成功的使用者: