開發十年，就只剩下這套架構體系了！ >>>   

一、引入Jedis依賴

可以新建Spring或Maven工程，在pom檔案中引入Jedis依賴：

<dependency>

<groupId>redis.clients</groupId>

<artifactId>jedis</artifactId>

<version>2.9.0</version>

</dependency>

二、Jedis工具類

JedisUtil.java

三、秒殺測試類（程式碼模擬多使用者+高併發）

RedisSecKiller.java

注：關於多執行緒部分程式碼的說明

傳統的方式是使用new Thread來建立、執行（start）執行緒，但那樣太低效了；使用定長執行緒池 + ExecutorService的execute方法來建立、執行執行緒，比前者高效得多。

四、執行結果

4.1 Redis資料插入結果

進入RedisManager -> db0檢視

4.2 IDEA控制檯輸出結果

五、有趣的測試

5.1 使用者數量小於商品數量，且等於最大併發數

將RedisSecKiller類中的USER_NUM從100改為5，因為此時N_THREADS仍然為5，最大併發數仍為5，即有5個使用者同時在搶購10件商品。注意，只要最大併發數大於等於使用者數量，就會造成所有使用者同時搶購商品（高併發）的情況出現。

執行結果如下：

5.2 使用者數量小於商品數量，且大於最大併發數

將N_THREADS從5改為3，此時有5名顧客搶購10件商品，但最多隻有三名顧客在同一時刻搶購。執行結果：

5.3 總結

（1）歡迎加入QQ群架構華山論劍：836442475【點選進入】（大牛聚集地）進我的私人群討論技術和學習！

（2）由5.1和5.2對比可知，當用戶數量小於商品數量時，併發訪問量越大，使用者秒殺到商品的成功率就會越低，因為併發量越大，可以進行的秒殺輪數就會越少，能搶購到商品的使用者也就越少。

（3）5.1和5.2中的假設其實是不合理的，如果使用者數量小於商品數量，供大於求，那也就不應該存在高併發秒殺的概念了，即使此時強行製造秒殺這個概念，但因為庫存充足，所以也應該讓所有使用者都搶購到商品，只是搶到的先後順序不同而已。

一個真實的網上商城的秒殺活動應該存在如下關係：使用者數量（線上）>> 商品數量 > 使用者併發數，舉例：

由1W臺手機等待秒殺，線上等待秒殺活動開始的使用者數量為10W，使