作者：京東科技 張石磊
1 案例引入
名詞簡介：
資源：可以理解爲一條內容，或者圖+文字+鏈接的載體。
檔位ID: 資源的分類組，資源必須歸屬於檔位。
問題描述：當同一個檔位下2條資源同時審批通過時，收到擎天審批系統2條消息，消費者應用部署了2臺機器，此時正好由2臺機器分別消費，在併發消費時，先更新資源狀態，然後寫緩存，每次取前100條資源，類似select * from resource where gear_id=xxx limit 100 order by id desc;
在寫檔位緩存，此時事務未提交，併發查詢時根據檔位Id查詢時查詢不到對方的數據，全量寫緩存時導致後寫的緩存覆蓋了先寫的緩存，即緩存被覆蓋，導致投放資源缺失。
方案思考 ：
方案1：一臺機器消費mq–單點問題
方案2：將同檔位ID的資源路由到同一個queue,需要審批系統配合根據檔位Id做路由，審批系統發的消息不只是cms審批數據，此方案不適用。
方案3：在檔位級別加分佈式鎖。
經比較，最終採用方案3是合適的方案.
2 鎖說明和分佈式鎖選擇
synchronized鎖的粒度是JVM進程維度，集羣模式下，不能對共享資源加鎖，此時需要跨JVM進程的分佈式鎖。
分佈式鎖方式核心實現方式優點缺點分析
1 數據庫：
悲觀鎖，lock
樂觀鎖，通過版本號實現version
實現簡單，不依賴中間件
數據庫IO瓶頸，性能差
單實例存在單點問題，主從架構存在數據不一致，主從切換時其他客戶端可重複加鎖。
2 zookeeper
創建臨時節點
CP模型，可靠性高，不存在主從切換不一致問題
頻繁創建和銷燬臨時節點，且
集羣模式下，leader數據需要同步到follower纔算加鎖成功，性能不如redis
主從切換服務不可用
3 redis集羣
setnx+expire
性能高
有封裝好的框架redission
支持超時自動刪除鎖
集羣支持高可用，AP模型
主從切換時其他客戶端可重複加鎖。
R2M是基於開源的Redis cluster(Redis 3.0以上版本)構建的高性能分佈式緩存系統，我們系統一直在使用，3.2.5版本開始支持分佈式鎖。
3 r2m分佈式鎖原理
示例代碼：
String lockKey = CacheKeyHelper.getGearLockKey(EnvEnum.getEnvFlagEnum(envCode),resource.getGearId());
R2mLock lock = (R2mLock) r2mClusterClient.getLock(lockKey);
//獲取鎖，鎖的默認有效期30s,獲取不到鎖就阻塞
lock.lock();
try {
//業務代碼
resourceService.afterApprovedHandle(resource);
} finally {
//釋放鎖
lock.unlock();
}
1 加鎖核心流程：
加鎖流程圖：
1）：嘗試獲取鎖，通過執行加鎖Lua腳本來做；
2）：若第一步未獲取到鎖，則去redis訂閱解鎖消息
3）：一旦持有鎖的線程釋放了鎖，就會廣播解鎖消息，其他線程自旋重新嘗試獲取鎖。
核心加鎖原理：使用lua腳本封裝了hset和pexpire命令，保證是一個原子操作， KEYS[1]是加鎖的key,argv[2]是加鎖的客戶端ID(UUID+線程ID),ARGV[1]是鎖的有效期，默認30s.
private Object acquireInternal(List<String> args) {
if (!this.setLocked() && this.getHolderId() != Thread.currentThread().getId()) {
return -1L;
} else {
try {
//hash結構，hash的key是加鎖的key,鍵值對的key爲客戶端的UUID+線程id,value爲鎖的重入計數器值。
return this.lockSha() != null ? this.executor.evalR2mLockSha(this.lockSha(),
"if (redis.call('exists', KEYS[1]) == 0) then redis.call('hset', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end;
if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end;
return -2;", Collections.singletonList(this.lockName), args) : this.executor. == 0) then redis.call('hset', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; return -2;", Collections.singletonList(this.lockName), args);
} catch (Exception var3) {
this.setUnlocked();
throw new R2mLockException("Failed to acquire lock " + this.lockName + ".", var3);
}
}
}
args參數
private List<String> acquireArgs(long leaseTime) {
List<String> args = new ArrayList();
if (leaseTime != -1L) {
args.add(String.valueOf(leaseTime));
} else {
//默認30s
args.add(String.valueOf(this.internalLockLeaseTime()));
}
//UUID+當前線程id
args.add(this.currentThreadLockId(Thread.currentThread().getId()));
return args;
}
獲取鎖失敗訂閱鎖的channel
//獲取鎖失敗，訂閱釋放鎖的消息
private boolean failedAcquire() {
this.subLock();
return false;
}
private void subLock() {
CompletableFuture<Void> cf = R2mLock.this.executor.lockSubscribe(R2mLock.this.lockPubSub(), R2mLock.this.getLockChannelName(), R2mLock.this);
if (cf != null) {
cf.handleAsync(this::reSubIfEx);
}
}
鎖釋放後，訂閱者通過自旋嘗試獲取鎖。
//tryAcquire獲取鎖，！tryAcquire就是獲取鎖失敗，鎖釋放後，通知線程喚醒後返回false,然後通過自旋，嘗試獲取鎖，
public final void acquire(long arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
final boolean acquireQueued(final Node node, long arg) {
boolean failed = true;
try {
boolean interrupted = false;
//內部自旋獲取鎖
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
2 釋放鎖核心邏輯：
1）刪除分佈式鎖key（如果可重入鎖計數爲0）
- 發釋放鎖的廣播消息
3）取消watchdog
private Object unlockInternal(List<String> args) {
logger.debug("{} trying to unlock.", Thread.currentThread().getId());
Object var2;
try {
//判斷鎖 key 是否存在，如果存在，然後遞減hash的value值，當value值爲0時再刪除鎖key，並且廣播釋放鎖的消息
if (this.unlockSha() == null) {
var2 = this.executor. == 0) then return nil;end; local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); if (counter > 0) then return 0; else redis.call('del', KEYS[1]); redis.call('publish', KEYS[2], ARGV[1]); return 1; end; return nil;", Arrays.asList(this.lockName, this.getLockChannelName()), args);
return var2;
}
var2 = this.executor.evalR2mLockSha(this.unlockSha(), "if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then return nil;end; local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); if (counter > 0) then return 0; else redis.call('del', KEYS[1]); redis.call('publish', KEYS[2], ARGV[1]); return 1; end; return nil;", Arrays.asList(this.lockName, this.getLockChannelName()), args);
} catch (Exception var6) {
throw new R2mLockException("Failed to unlock " + this.lockName + ".", var6);
} finally {
this.finalizeRelease();
}
return var2;
}
//取消當前線程的watchdog
private void finalizeRelease() {
long threadId = Thread.currentThread().getId();
R2mLock.ExpirableEntry entry = (R2mLock.ExpirableEntry)this.entryCache.get(threadId);
if (entry != null) {
entry.release(threadId);
if (entry.isReleased()) {
//取消這個線程watchdog定時任務
entry.getExtTask().cancel();
this.expEntry.compareAndSet(entry, (Object)null);
//從緩存watchdog線程的map中刪除該線程
this.entryCache.remove(threadId);
}
}
}
3 鎖的健壯性思考
1 業務沒執行完，鎖超時過期怎麼辦？
客戶端加鎖默認有效期30s，超過有效期後如果業務沒執行完，還需要持有這把鎖，r2m客戶端提供了續期機制，也就是watchdog機制。
watchdog原理：客戶端線程維度（UUID+線程ID,客戶端維護一個MAP,key就是UUID+線程ID）的後臺定時線程，獲取鎖成功後，如果客戶端還持有當前鎖，每隔10s(this.internalLockLeaseTime() / 3L)，去延長鎖的有效期（internalLockLeaseTime）
//watchdog核心機制 ，internalLockLeaseTime默認30s
private void extendLock(long holderId) {
if (this.expEntry.get() != null) {
R2mLock.ExpirableEntry holderEntry = (R2mLock.ExpirableEntry)this.entryCache.get(holderId);
if (holderEntry != null) {
//每隔10s,如果當前線程持有鎖，則續期30s
if (this.expEntry.compareAndSet(holderEntry, holderEntry)) {
Timeout task = this.timer().newTimeout((timeout) -> {
if (this.extendLockInternal(holderId)) {
this.extendLock(holderId);
}
}, this.internalLockLeaseTime() / 3L, TimeUnit.MILLISECONDS);
if (this.expEntry.get() != null) {
((R2mLock.ExpirableEntry)this.expEntry.get()).setExtTask(task);
}
}
}
}
}
//執行續期lua腳本
private boolean extendLockInternal(long threadId) {
Object result;
try {
//只續期
if (this.extendLockSha() != null) {
result = this.executor.evalR2mLockSha(this.extendLockSha(), "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('pexpire', KEYS[1], ARGV[1]); return 1; end; return 0;", Collections.singletonList(this.lockName), this.extendLockArgs(threadId));
} else {
result = this.executor. == 1) then redis.call('pexpire', KEYS[1], ARGV[1]); return 1; end; return 0;", Collections.singletonList(this.lockName), this.extendLockArgs(threadId));
}
} catch (Exception var5) {
return false;
}
return Long.parseLong(result.toString()) == 1L;
}
2 客戶端宕機，鎖如何釋放？
分佈式鎖是有效期的，客戶端宕機後，watchdog機制失效，鎖過期自動失效。
3 redis分佈式鎖集羣模式下缺陷
r2m集羣模式，極端情況，master加鎖成功，宕機，還未來得及同步到slave,主從切換，slave切換成master,可以繼續加鎖，對於非及其嚴格加鎖場景，該方案可滿足，屬於AP；對於嚴格場景下的分佈式鎖，可採用基於zookeeper的分佈式鎖，屬於CP，leader宕機，folllower選舉時不可用。性能上redis更優。
4 鎖的釋放問題
注意鎖的釋放在finally中釋放，必須由鎖的持有者釋放，不能由其他線程釋放別人的鎖，示例代碼中lock放到try的外面。