1. 準備工作
1.1 理論基礎
在併發場景下，實現資料的正確寫入，主要需理解“鎖”相關的原理和技術。
併發時寫資料，需要考慮要不要上鎖，根本原因是，資料存在共享且資料會發生變化，即多執行緒會同時讀寫同一資料。 若資料不存在共享，即不同的執行緒讀寫不同的資料，不需要上鎖； 若資料共享，所有執行緒對資料只讀不寫，也不需要上鎖 若資料共享，有的執行緒讀資料，有的執行緒寫資料，則需要上鎖。
當多個執行緒同時訪問同一資料，並且至少有一個執行緒會寫這個資料，這種情況被稱之為“資料競爭”。
併發場景下，鎖的作用，是併發改為序列，以保證資料的一致性（更具體而言，通過上鎖，解決了併發執行程式時的原子性、可見性和有序性問題，有興趣的同學可以近一步深入相關理論，本文以實戰為主，不在展開）。
故，在併發場景下讀寫資料，首先要分析是否存在“資料競爭”問題，若存在，需要“上鎖”。資料競爭如果發生在本地應用中，則用本地鎖；如果發生在分散式服務間中，則使用分散式鎖；本地鎖和分散式鎖在原理上相同，不用分別討論。
鎖相關技術，有“悲觀鎖”和“樂觀鎖”兩種。
（1）悲觀鎖
我們通常說的鎖，如無特殊說明，就是指“悲觀鎖”。它是通過一些技術手段，實現執行緒或服務間的互斥和同步，其使用時，有顯示（或隱式）的鎖持有/釋放操作。 由於上鎖本身要損耗效能，上鎖後併發處理變成序列，故上鎖是比較影響系統效能的操作；且鎖的應用不當，會潛在死鎖/活鎖風險；故悲觀鎖的使用要慎重。
（2）樂觀鎖
樂觀鎖通常又叫“無鎖技術”，它不是通過“上鎖”把併發改序列的方式保證資料一致性，而是通過CAS(Compare And Swap)方式來實現，由於CAS通常很快，該過程也不用“上鎖”，效能損耗少。不過，通過CAS併發寫資料時，通常伴有“自旋”，即當出現多個寫併發時，只有一個能寫入成功，其他要自旋後再次寫入，直至寫入成功或因超時/超過重試次數失敗。 自旋會帶來效能開銷，頻繁自旋的效能開銷會超過上鎖。故樂觀鎖通常用在併發不太激烈的場景中，且在該場景下效能比悲觀鎖要好，而在高併發場景下，建議使用悲觀鎖。
1.2 業務場景及分析
本文主題是介紹併發寫資料的幾種方案，為此，我們先確立幾個常用的業務場景，並做簡單分析。
寫資料，我們討論最常見的把資料寫入資料庫的場景，主要包括新建資料和修改資料兩種具體場景，兩個場景不完全一致，分別討論。
（1） 往資料庫寫新資料
往資料庫裡寫信資料時，如果資料直接相互獨立，即不存在“資料競爭”，則按照1.1節的理論，此時不需要考慮鎖的問題。
對於存在“資料競爭”的場景，我們考慮寫入流水碼的場景：假設建立資料有個編碼欄位，形如“CON_0001”，其後半段的“0001”是流水碼，需要根據當前最大的流水碼+1 來計算待建立資料的流水碼。這裡存在資料範圍的競爭，併發建立資料時，如果不做併發控制，會建立多個編碼相同的資料。
（2）更新資料庫記錄
併發更新資料庫記錄時，如果可以確保各併發請求要更新的資料各不相同，則不存在“資料競爭”，不需要上鎖；而併發更新同一資料記錄時，如果不做併發控制，可能出現一個寫請求覆蓋另一個寫請求的情況，導致最終結果錯誤。
這裡我們考慮“訪問量+1”的場景，即設計一個訪問量表，每次請求給訪問量+1，如當前訪問量為5，若5個併發請求同時為該記錄+1，正確的結果為10，但如果不加併發控制，結果通常會<10。
2. 併發插入流水碼的實現方案
2.1 業務邏輯分析
業務邏輯如下：
- 取出當前資料庫中流水碼最大的一條記錄
- 從編碼欄位中解析出當前最大流水碼
- 流水碼+1，建立新紀錄入庫
程式碼實現即：
private Integer addEntity() {
ConcurrentEntity entity = dataMapper.getLatestConcurrentEntity();
int nextNumber = entity == null ? 1 : getNextNumberByCode(entity.getCode());
String code = String.format("CON_%04d", nextNumber);
return dataMapper.insertConcurrentEntity(new ConcurrentEntity(code));
}
private int getNextNumberByCode(String code) {
int index = code.lastIndexOf("_");
String number = code.substring(index + 1);
return Integer.parseInt(number) + 1;
}
該業務在併發場景下，主要存在原子性隱患，即addEntity()中的程式碼，需要作為一個整體全部執行完，若多個執行緒交替執行執行逐行程式碼，某個執行緒讀取到最新流水碼後，該碼被其他執行緒改了，本執行緒不可知，導致寫入錯誤資料。
故本業務場景的併發中，主要避免原子性和可見性問題，最直接的方式，是通過上鎖解決。
2.2 實現方案
2.2.1 方案1：在程式碼中上鎖
private final Lock lock = new ReentrantLock(false);
public Integer addEntityByLock() {
synchronized (this) {
return addEntity();
}
}
public Integer addEntityByLock2() {
lock.lock();
try {
return addEntity();
} finally {
lock.unlock();
}
}
在分散式系統中，lock可以用redisson或curator提供的分散式鎖進行例項化。
2.2.2 方案2: 在資料庫中上鎖
鎖除了可以在程式碼中用，也可以直接用到資料庫上，select ... for update語句即可在資料庫中上寫鎖，另由於業務執行的原子性問題，需要把addEntity()中的邏輯放到同一個事務中去。
@Transactional(isolation = Isolation.REPEATABLE_READ)
public Integer addEntityByTransactionWithLock() {
return addEntity();
}
這裡的事務隔離級別，選擇RC或RR均可。
注，這個實現中，addEntity()中對ConcurrentEntity的查詢，改成了加鎖讀的方式：
@Select("SELECT * FROM concurrent_entity\n" +
"ORDER BY code DESC\n" +
"LIMIT 1\n" +
"FOR UPDATE;")
ConcurrentEntity getLatestConcurrentEntityWithWriteLock();
2.2.3 效能對比
對於1000個併發請求，三種方法效能對比如下：
executeConcurrentAddByLock1: 1000 併發，花費時間 1179 ms
executeConcurrentAddByLock2: 1000 併發，花費時間 863 ms
executeConcurrentAddByTransactionWithLock: 1000 併發，花費時間 1284 ms
2.3 其他方案
本業務場景中，由於流水碼的計算，存在資料競爭問題，所以併發時需要上鎖，如果能避免資料競爭，就可以避免併發問題。針對本案例，可以把流水碼獲取的邏輯放到redis中去，redis本身是單執行緒的，避免了流水碼的資料競爭，進而避免了上鎖的開銷，而redis本身又是高效能的，故這個方案理論上比上述方案的效能只高不低。
3. 併發更新訪問量的實現方案
3.1 業務分析
併發更新資料庫中的訪問量時，存在的“資料競爭”問題，也是“原子性”隱患。如果更新本身是一個原子操作，則不存在併發問題；如果更新操作分兩步，先讀取當前資料，然後+1後重新寫入，則該操作不是原子的，需要上鎖。
3.2 實現方案
3.2.1 方案1: 原子更新
public Integer increaseVisitCountAtomically(int id) {
return dataMapper.increaseConcurrentVisitAtomic(id);
}
@Update("UPDATE concurrent_visit\n" +
"SET visit = visit + 1, update_time = NOW()\n" +
"WHERE id = #{id};")
Integer increaseConcurrentVisitAtomic(int id);
3.2.2 方案2: 程式碼中上鎖
public Integer increaseVisitCountByLock(int id) {
synchronized (this) {
return increaseVisitCount(id);
}
}
private Integer increaseVisitCount(int id) {
ConcurrentVisit concurrentVisit = dataMapper.getConcurrentVisitObject(id);
concurrentVisit.increaseVisit().updateUpdateTime();
return dataMapper.updateConcurrentVisit(concurrentVisit);
}
3.2.3 方案3: 資料庫中上鎖
@Transactional()
public Integer increaseVisitCountByTransaction(int id) {
return increaseVisitCount(id, true);
}
private Integer increaseVisitCount(int id, boolean withLock) {
ConcurrentVisit concurrentVisit = withLock ? dataMapper.getConcurrentVisitObjectWithLock(id)
: dataMapper.getConcurrentVisitObject(id);
return dataMapper.increaseConcurrentVisit(concurrentVisit.increaseVisit().updateUpdateTime());
}
@Select("SELECT * FROM concurrent_visit\n" +
"WHERE id = #{id}\n" +
"FOR UPDATE;")
ConcurrentVisit getConcurrentVisitObjectWithLock(int id);
3.2.4 方案4: 使用樂觀鎖
使用樂觀鎖時，需要一個遞增的版本欄位（version），每次update 成功時，version都要 +1，version要作為更新前的compare欄位，若當前讀到的version與資料庫中的version不一致，則更新失敗。
public Integer increaseVisitCountOptimistically(int id) {
ConcurrentVisit concurrentVisit = dataMapper.getConcurrentVisitObject(id);
return dataMapper.increaseConcurrentVisitOptimistically(concurrentVisit.increaseVisit().updateUpdateTime());
}
@Update("UPDATE concurrent_visit\n" +
"SET visit = #{visit}, update_time = #{updateTime}, version = #{version} + 1\n" +
"WHERE id = #{id} and version = #{version};")
Integer increaseConcurrentVisitOptimistically(ConcurrentVisit concurrentVisit);
使用樂觀鎖時，compare不一致，會更新失敗，這時需要自旋重試，故上述程式碼可以優化為：
public Integer increaseVisitCountOptimisticallyWithRetry(int id) {
int result = 0;
int maxRetry = 5;
long interval = 20L;
for (int i = 0; i < maxRetry; i++) {
result = increaseVisitCountOptimistically(id);
if (result > 0) {
break;
}
interval = interval + i * 50;
helper.sleep(interval);
}
return result;
}
3.2.5 效能比較
發起10000個併發更新操作，結果如下：
executeConcurrentAddAtomically: 10000 併發，花費時間 2112 ms
executeConcurrentAddByLock: 10000 併發，花費時間 5796 ms
executeConcurrentAddByTransaction: 10000 併發，花費時間 3902 ms
executeConcurrentAddOptimisticallyWithRetry: 10000 併發，花費時間 5998 ms
mysql> select * from concurrent_visit;
+----+-------------+-------+---------+---------------------+---------------------+
| id | resourceKey | visit | version | create_time | update_time |
+----+-------------+-------+---------+---------------------+---------------------+
| 1 | resource1 | 39925 | 9925 | 2022-03-31 11:42:54 | 2022-04-01 12:06:36 |
+----+-------------+-------+---------+---------------------+---------------------+
可以看到：
- 併發比較激烈時，樂觀鎖效能最差，而且有些請求，即使超過了最大重試次數，也沒更新成功
- 把鎖上在資料庫中，效能比所在程式碼上還要好，原因是，資料庫上的鎖是經過充分的效能優化的，而且鎖的顆粒度更小，而我們這個業務場景下，程式碼中鎖的顆粒度已經很難再縮小了。鎖的顆粒度，決定了併發程度，併發場景下，鎖的顆粒度越小越好
What's More
本文相關程式碼，可以在我GitHub的concurrent-write-db 中檢視
本文同步發表於我的微信公眾號，歡迎關注。
注：轉載本文，請與Gevin聯絡
歡迎關注我的微信公眾賬號
