Github：https://github.com/nnngu
項目源代碼：https://github.com/nnngu/nguSeckill
關於並發
並發性上不去是因為當多個線程同時訪問一行數據時，產生了事務，因此產生寫鎖，當一個獲取了事務的線程把鎖釋放，另一個排隊線程才能拿到寫鎖，QPS(Query Per Second每秒查詢率)和事務執行的時間有密切關系，事務執行時間越短，並發性越高，這也是要將費時的 IO 操作移出事務的原因。
項目中的高並發發生在哪？
下圖中，紅色的部分就表示會發生高並發的地方，綠色部分表示對於高並發沒有影響。
為什么要單獨獲取系統時間？
這是為了我們的秒殺系統的優化做鋪墊。比如在秒殺還未開始的時候，用戶大量刷新秒殺商品詳情頁面是很正常的情況，這時候秒殺還未開始，大量的請求發送到服務器會造成不必要的負擔。
我們將這個詳情頁放置到CDN中，這樣用戶在訪問該頁面時就不需要訪問我們的服務器了，起到了降低服務器壓力的作用。而CDN中存儲的是靜態化的詳情頁和一些靜態資源（css，js等），這樣我們就拿不到系統的時間來進行秒殺時段的控制，所以我們需要單獨設計一個請求來獲取我們服務器的系統時間。
CDN（Content Delivery Network）的理解
獲取系統時間不需要優化
因為Java訪問一次內存（Cacheline）大約10ns，1s=10億ns，也就是如果不考慮GC，這個操作1s可以做1億次。
秒殺地址接口分析
-
無法使用CDN緩存，因為CDN適合請求對應的資源不變化的，比如靜態資源、JavaScript；秒殺地址返回的數據是變化的，不適合放在CDN緩存；
-
適合服務端緩存：Redis等，1秒鍾可以承受10萬QPS。多個Redis組成集群，可以到100萬個QPS。所以后端緩存可以用業務系統控制。
秒殺地址接口優化
秒殺操作優化分析
-
無法使用cdn緩存
-
后端緩存困難： 庫存問題
-
一行數據競爭：熱門商品
大部分寫的操作和核心操作無法使用CDN，也不可能在緩存中減庫存。你在Redis中減庫存，那么用戶也可能通過緩存來減庫存，這樣庫存會不一致，所以要通過mysql的事務來保證一致性。
比如一個熱門商品所有人都在搶，那么會在同一時間對數據表中的一行數據進行大量的update set操作。
行級鎖在commit之后才釋放，所以優化方向是減少行級鎖的持有時間。
延遲問題很關鍵
-
同城機房網絡（0.5ms~2ms），最高並發性是1000qps。
-
update后JVM -GC(垃圾回收機制)大約50ms，最高並發性是20qps。並發性越高，GC就越可能發生，雖然不一定每次都會發生，但一定會發生。
-
異地機房，比如北京到上海之間的網絡延遲，經過計算大概13~20ms。
如何判斷update更新庫存成功？
有兩個條件：
-
update自身沒報錯；
-
客戶端確認update影響記錄數
優化思路：把客戶端邏輯放到MySQL服務端，避免網絡延遲和GC影響
如何把客戶端邏輯放到MySQL服務端
有兩種方案：
-
定制SQL方案，在每次update后都會自動提交，但需要修改MySQL源碼，成本很高，不是大公司（BAT等）一般不會使用這種方法。
-
使用存儲過程：整個事務在MySQL端完成，用存儲過程寫業務邏輯，服務端負責調用。
接下來先分析第一種方案
根據上圖的成本分析，我們的秒殺系統采用第二種方案，即使用存儲過程。
優化總結
-
前端控制。暴露接口，按鈕防重復（點擊一次按鈕后就變成灰色，禁止重復點擊按鈕）
-
動靜態數據分離。CDN緩存，后端緩存
-
事務競爭優化。減少事務行級鎖的持有時間
下載安裝Redis
Redis是一個開源的、支持網絡、可基於內存亦可持久化的日志型、Key-Value數據庫
下載安裝Redis的步驟，搜索引擎能找到相關的資料，本文不做展開。
下載安裝完Redis之后就可以繼續進行操作。
使用Java操作Redis
Java操作Redis使用的是jedis包。
在pom.xml添加jedis的依賴，如下圖：
添加protostuff-core 以及protostuff-runtime 序列化jar包，如下圖：
序列化是處理對象流的機制，就是將對象的內容進行流化，可以對流化后的對象進行讀寫操作，也可以將流化后的對象在網絡間傳輸。反序列化就是將流化后的對象重新轉化成原來的對象。
在Java中內置了序列化機制，通過implements Serializable來標識一個對象實現了序列化接口，不過其性能並不高。
建立操作Redis的dao類
原本查詢秒殺商品時是通過主鍵直接去數據庫查詢的，選擇將數據緩存在Redis，在查詢秒殺商品時先去Redis緩存中查詢，以此降低數據庫的壓力。如果在緩存中查詢不到數據再去數據庫中查詢，再將查詢到的數據放入Redis緩存中，這樣下次就可以直接去緩存中直接查詢到。
添加RedisDao.java文件，位於下圖所示的位置：
RedisDao.java文件里面的代碼請參照項目的源代碼。
在applicationContext-dao.xml中注入redisDao
在applicationContext-dao.xml中添加下圖所示的內容：
改造exportSeckillUrl方法：
修改SeckillServiceImpl.java文件中的exportSeckillUrl方法：
/**
* 在秒殺開啟時輸出秒殺接口的地址，否則輸出系統時間跟秒殺地址
*
* @param seckillId 秒殺商品Id
* @return 根據對應的狀態返回對應的狀態實體
*/
@Override
public Exposer exportSeckillUrl(long seckillId) {
Seckill seckill = redisDao.getSeckill(seckillId);
if (seckill == null) {
// 訪問數據庫讀取數據
seckill = seckillMapper.queryById(seckillId);
if (seckill == null) {
return new Exposer(false, seckillId);
} else {
// 放入redis
redisDao.putSeckill(seckill);
}
}
// 判斷是否還沒到秒殺時間或者是過了秒殺時間
Date startTime = seckill.getStartTime();
Date endTime = seckill.getEndTime();
Date nowTime = new Date();
// 開始時間大於現在的時候說明沒有開始秒殺活動；秒殺活動結束時間小於現在的時間說明秒殺已經結束了
if (nowTime.getTime() > startTime.getTime() && nowTime.getTime() < endTime.getTime()) {
//秒殺開啟,返回秒殺商品的id,用給接口加密的md5
String md5 = getMd5(seckillId);
return new Exposer(true, md5, seckillId);
}
return new Exposer(false, seckillId, nowTime.getTime(), startTime.getTime(), endTime.getTime());
}
簡單的優化
以前的實現流程：
用戶的秒殺操作分為兩步：減庫存、插入購買明細，我們在這里進行簡單的優化，就是將原本先update（減庫存）再進行insert（插入購買明細）的步驟改成：先insert再update。
為什么要先insert再update
-
首先是在更新操作的時候給行加鎖，插入並不會加鎖，如果更新操作在前，那么就需要執行完更新和插入以后事務提交或回滾才釋放鎖。而如果插入在前，更新在后，那么只有在更新時才會加行鎖，之后在更新完以后事務提交或回滾釋放鎖。
-
在這里，插入是可以並行的，而更新由於會加行級鎖是串行的。
-
也就是說是如果更新在前，加鎖和釋放鎖之間兩次的網絡延遲和GC，如果更新在后，則加鎖和釋放鎖之間只有一次的網絡延遲和GC，也就是減少的持有鎖的時間。
-
這里先insert並不是忽略了庫存不足的情況，而是因為insert和update是在同一個事務里，光是insert並不一定會提交，只有在update成功才會提交，所以並不會造成過量插入秒殺成功記錄。
去代碼里改造執行秒殺的executeSeckill()方法，優化性能。
深度優化（使用存儲過程）
前邊通過調整insert和update的執行順序來實現簡單的優化，但依然存在着Java客戶端和服務器通信時的網絡延遲和GC影響，我們可以將執行秒殺操作時的insert和update放到MySQL服務端的存儲過程里，而Java客戶端直接調用這個存儲過程，這樣就可以避免網絡延遲和可能發生的GC影響。另外，由於我們使用了存儲過程，也就用不到Spring的事務管理了，因為在存儲過程里我們會直接啟用一個事務。
去MySQL的控制台執行儲存過程procedure.sql里面的代碼
去MySQL的控制台執行儲存過程procedure.sql里面的代碼。
procedure.sql文件位於項目的sql目錄下。
注意點：在存儲過程中，row_count() 函數用來返回上一條 sql（delete, insert, update）影響的行數。
根據row_count() 的返回值，可以進行接下來的流程判斷：
0：未修改數據；
>0：表示修改的行數；
<0：表示SQL錯誤或未執行修改SQL
修改源碼以調用存儲過程
在SeckillMapper.java接口中聲明killByProcedure()方法
/**
* 使用儲存過程執行秒殺
*
* @param paramMap
*/
void killByProcedure(Map<String, Object> paramMap);
然后在SeckillMapper.xml中寫sql語句，具體代碼請參照項目的源代碼。
接着在SeckillService.java接口中聲明 executeSeckillProcedure()方法
在pom.xml中添加commons-collections的依賴，如下圖：
然后在SeckillServiceImpl.java中實現executeSeckillProcedure()方法。
在SeckillServiceImplTest.java中編寫測試方法executeSeckillProcedureTest()。
測試結果：
修改SeckillController.java中的execute()方法，把一開始調用普通方法的改成調用儲存過程的方法。
存儲過程優化總結
-
存儲過程優化：事務行級鎖持有的時間
-
不要過度依賴存儲過程
-
簡單的邏輯依賴存儲過程
-
QPS:一個秒殺單6000/qps
經過簡單優化和深度優化之后，本項目大概能達到一個秒殺單6000qps，這個數據對於一個秒殺商品來說其實已經挺ok了，注意這里是指同一個秒殺商品6000qps，如果是不同商品不存在行級鎖競爭的問題。
系統部署架構
CDN：放置一些靜態化資源，或者可以將動態數據分離。一些js依賴直接用公網的CDN，自己開發的一些頁面也做靜態化處理推送到CDN。用戶在CDN獲取到的數據不需要再訪問我們的服務器，動靜態分離可以降低服務器請求量。比如秒殺詳情頁，做成HTML放在CDN上，動態數據可以通過ajax請求后台獲取。
Nginx：作為http服務器，響應客戶請求，為后端的servlet容器做反向代理，以達到負載均衡的效果。
Redis：用來做服務器端的緩存，通過Jedis提供的API來達到熱點數據的一個快速存取的過程，減少數據庫的請求量。
MySQL：保證秒殺過程的數據一致性與完整性。
智能DNS解析+智能CDN加速+Nginx並發+Redis緩存+MySQL分庫分表，如下圖：
大型系統部署架構，邏輯集群就是開發的部分。
-
Nginx做負載均衡
-
分庫分表：在秒殺系統中，一般通過關鍵的秒殺商品id取模進行分庫分表，以512為一張表，1024為一張表。分庫分表一般采用開源架構，如阿里巴巴的tddl分庫分表框架。
-
統計分析：一般使用hadoop等架構進行分析
在這樣一個架構中，可能參與的角色如下：
到此，該項目已經全部完成，感謝閱讀本文。
我的博客即將搬運同步至騰訊雲+社區，邀請大家一同入駐：https://cloud.tencent.com/developer/support-plan