基于Redis的實(shí)現(xiàn)方式
1、選用Redis實(shí)現(xiàn)分布式鎖原因：
（1）Redis有很高的性能；
（2）Redis命令對此支持較好，實(shí)現(xiàn)起來比較方便
2、使用命令介紹：
（1）SETNX
SETNX key val：當(dāng)且僅當(dāng)key不存在時(shí)，set一個(gè)key為val的字符串，返回1；若key存在，則什么都不做，返回0。
（2）expire
expire key timeout：為key設(shè)置一個(gè)超時(shí)時(shí)間，單位為second，超過這個(gè)時(shí)間鎖會(huì)自動(dòng)釋放，避免死鎖。
（3）delete
delete key：刪除key
在使用Redis實(shí)現(xiàn)分布式鎖的時(shí)候，主要就會(huì)使用到這三個(gè)命令。
3、實(shí)現(xiàn)思想：
（1）獲取鎖的時(shí)候，使用setnx加鎖，并使用expire命令為鎖添加一個(gè)超時(shí)時(shí)間，超過該時(shí)間則自動(dòng)釋放鎖，鎖的value值為一個(gè)隨機(jī)生成的UUID，通過此在釋放鎖的時(shí)候進(jìn)行判斷。
（2）獲取鎖的時(shí)候還設(shè)置一個(gè)獲取的超時(shí)時(shí)間，若超過這個(gè)時(shí)間則放棄獲取鎖。
（3）釋放鎖的時(shí)候，通過UUID判斷是不是該鎖，若是該鎖，則執(zhí)行delete進(jìn)行鎖釋放。
4、 分布式鎖的簡單實(shí)現(xiàn)代碼：
/**
* 分布式鎖的簡單實(shí)現(xiàn)代碼
* Created by liuyang on 2017/4/20.
*/
public class DistributedLock {
private final JedisPool jedisPool;
public DistributedLock(JedisPool jedisPool) {
this.jedisPool = jedisPool;
}
/**
* 加鎖
* @param lockName 鎖的key
* @param acquireTimeout 獲取超時(shí)時(shí)間
* @param timeout 鎖的超時(shí)時(shí)間
* @return 鎖標(biāo)識(shí)
*/
public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) {
Jedis conn = null;
String retIdentifier = null;
try {
// 獲取連接
conn = jedisPool.getResource();
// 隨機(jī)生成一個(gè)value
String identifier = UUID.randomUUID().toString();
// 鎖名，即key值
String lockKey = "lock:" + lockName;
// 超時(shí)時(shí)間，上鎖后超過此時(shí)間則自動(dòng)釋放鎖
int lockExpire = (int) (timeout / 1000);
// 獲取鎖的超時(shí)時(shí)間，超過這個(gè)時(shí)間則放棄獲取鎖
long end = System.currentTimeMillis() + acquireTimeout;
while (System.currentTimeMillis() < end) {
if (conn.setnx(lockKey, identifier) == 1) {
conn.expire(lockKey, lockExpire);
// 返回value值，用于釋放鎖時(shí)間確認(rèn)
retIdentifier = identifier;
return retIdentifier;
}
// 返回-1代表key沒有設(shè)置超時(shí)時(shí)間，為key設(shè)置一個(gè)超時(shí)時(shí)間
if (conn.ttl(lockKey) == -1) {
conn.expire(lockKey, lockExpire);
}
try {
Thread.sleep(10);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
} catch (JedisException e) {
e.printStackTrace();
} finally {
if (conn != null) {
conn.close();
}
}
return retIdentifier;
}
/**
* 釋放鎖
* @param lockName 鎖的key
* @param identifier 釋放鎖的標(biāo)識(shí)
* @return
*/
public boolean releaseLock(String lockName, String identifier) {
Jedis conn = null;
String lockKey = "lock:" + lockName;
boolean retFlag = false;
try {
conn = jedisPool.getResource();
while (true) {
// 監(jiān)視lock，準(zhǔn)備開始事務(wù)
conn.watch(lockKey);
// 通過前面返回的value值判斷是不是該鎖，若是該鎖，則刪除，釋放鎖
if (identifier.equals(conn.get(lockKey))) {
Transaction transaction = conn.multi();
transaction.del(lockKey);
List<Object> results = transaction.exec();
if (results == null) {
continue;
}
retFlag = true;
}
conn.unwatch();
break;
}
} catch (JedisException e) {
e.printStackTrace();
} finally {
if (conn != null) {
conn.close();
}
}
return retFlag;
}
}
5、測試剛才實(shí)現(xiàn)的分布式鎖
例子中使用50個(gè)線程模擬秒殺一個(gè)商品，使用–運(yùn)算符來實(shí)現(xiàn)商品減少，從結(jié)果有序性就可以看出是否為加鎖狀態(tài)。
模擬秒殺服務(wù)，在其中配置了jedis線程池，在初始化的時(shí)候傳給分布式鎖，供其使用。
/**
* Created by liuyang on 2017/4/20.
*/
public class Service {
private static JedisPool pool = null;
private DistributedLock lock = new DistributedLock(pool);
int n = 500;
static {
JedisPoolConfig config = new JedisPoolConfig();
// 設(shè)置最大連接數(shù)
config.setMaxTotal(200);
// 設(shè)置最大空閑數(shù)
config.setMaxIdle(8);
// 設(shè)置最大等待時(shí)間
config.setMaxWaitMillis(1000 * 100);
// 在borrow一個(gè)jedis實(shí)例時(shí)，是否需要驗(yàn)證，若為true，則所有jedis實(shí)例均是可用的
config.setTestOnBorrow(true);
pool = new JedisPool(config, "127.0.0.1", 6379, 3000);
}
public void seckill() {
// 返回鎖的value值，供釋放鎖時(shí)候進(jìn)行判斷
String identifier = lock.lockWithTimeout("resource", 5000, 1000);
System.out.println(Thread.currentThread().getName() + "獲得了鎖");
System.out.println(--n);
lock.releaseLock("resource", identifier);
}
}
模擬線程進(jìn)行秒殺服務(wù)：
public class ThreadA extends Thread {
private Service service;
public ThreadA(Service service) {
this.service = service;
}
@Override
public void run() {
service.seckill();
}
}
public class Test {
public static void main(String[] args) {
Service service = new Service();
for (int i = 0; i < 50; i++) {
ThreadA threadA = new ThreadA(service);
threadA.start();
}
}
}
結(jié)果如下，結(jié)果為有序的：
若注釋掉使用鎖的部分：
public void seckill() {
// 返回鎖的value值，供釋放鎖時(shí)候進(jìn)行判斷
//String indentifier = lock.lockWithTimeout("resource", 5000, 1000);
System.out.println(Thread.currentThread().getName() + "獲得了鎖");
System.out.println(--n);
//lock.releaseLock("resource", indentifier);
}
從結(jié)果可以看出，有一些是異步進(jìn)行的：
上述實(shí)現(xiàn)存在的問題
-
非原子性操作
??加鎖setnx和鎖超時(shí)expire兩個(gè)命令未非原子性操作，當(dāng)執(zhí)行加鎖setnx后，若因網(wǎng)絡(luò)或客戶端問題鎖超時(shí)expire命令未成功執(zhí)行時(shí)，鎖將無法被釋放。
解決方案：
??使用set命令取代setnx和expire命令。setnx本身不支持設(shè)置超時(shí)時(shí)間。在Redis 2.6.12以上版本為set指令增加了可選參數(shù)，偽代碼：set（key, value, expire）。
誤刪鎖
設(shè)想如下情形：
??（1）JVM1使用set(001, 002, 30)成功獲取鎖，并設(shè)置超時(shí)時(shí)間為30s；
??（2）JVM1開始數(shù)據(jù)處理，處理時(shí)間已經(jīng)超過了30s...
??（3）服務(wù)器檢測到(001, 002, 30)數(shù)據(jù)超時(shí)，將自動(dòng)執(zhí)行del進(jìn)行數(shù)據(jù)刪除，此時(shí)JVM1還在數(shù)據(jù)處理...
??（4）此時(shí)，JVM2使用set(001, 002, 30)成功獲取鎖，并設(shè)置超時(shí)時(shí)間為30s；
??（5）JVM2開始數(shù)據(jù)處理。與此同時(shí)，JVM1處理完成，操作提交后，根據(jù)商品id001，執(zhí)行了del；
??? 到此，JVM1成功誤刪了JVM2的鎖。
解決方案：
??del數(shù)據(jù)之前，增加鎖判斷機(jī)制：判斷要?jiǎng)h除的鎖是否屬于本線程。操作流程：
??（1）加鎖：set(id, threadId,expire)，其中value為當(dāng)前線程ID；
??（2）解鎖：執(zhí)行del命令時(shí)，根據(jù)id和threadId數(shù)據(jù)判斷該鎖是否仍屬于本線程。是，則刪除。-
并發(fā)問題
??基于誤刪鎖的前提下，由于我們無法確定程序成功處理完成數(shù)據(jù)的具體時(shí)間，這就為超時(shí)時(shí)間的設(shè)置提出了難題。設(shè)置時(shí)間過長、過短都將影響程序并發(fā)的效率。
解決方案：JVM1需要自己判斷在超時(shí)時(shí)間內(nèi)是否完成數(shù)據(jù)處理，如未完成，應(yīng)請求延長超時(shí)時(shí)間。具體操作：
??為獲取鎖的鎖的線程開啟一個(gè)守護(hù)線程。當(dāng)29秒時(shí)（或更早），線程A還沒執(zhí)行完，守護(hù)線程會(huì)執(zhí)行expire指令，為這把鎖“續(xù)命”20秒。守護(hù)線程從第29秒開始執(zhí)行，每20秒執(zhí)行一次。當(dāng)線程A執(zhí)行完任務(wù)，會(huì)顯式關(guān)掉守護(hù)線程。
image另一種情況：如果節(jié)點(diǎn)1 忽然斷電，由于線程A和守護(hù)線程在同一個(gè)進(jìn)程，守護(hù)線程也會(huì)停下。當(dāng)過了超時(shí)時(shí)間后，沒有守護(hù)進(jìn)程的“續(xù)命”，鎖將自動(dòng)釋放。
Redisson實(shí)現(xiàn)Redis分布式鎖的底層原理
好的，接下來就通過一張手繪圖，給大家說說Redisson這個(gè)開源框架對Redis分布式鎖的實(shí)現(xiàn)原理。
（1）加鎖機(jī)制
咱們來看上面那張圖，現(xiàn)在某個(gè)客戶端要加鎖。如果該客戶端面對的是一個(gè)redis cluster集群，他首先會(huì)根據(jù)hash節(jié)點(diǎn)選擇一臺(tái)機(jī)器。
這里注意，僅僅只是選擇一臺(tái)機(jī)器！這點(diǎn)很關(guān)鍵！
緊接著，就會(huì)發(fā)送一段lua腳本到redis上，那段lua腳本如下所示：
為啥要用lua腳本呢？
因?yàn)橐淮筵鐝?fù)雜的業(yè)務(wù)邏輯，可以通過封裝在lua腳本中發(fā)送給redis，保證這段復(fù)雜業(yè)務(wù)邏輯執(zhí)行的原子性。
那么，這段lua腳本是什么意思呢？
KEYS[1]代表的是你加鎖的那個(gè)key，比如說：
RLock lock = redisson.getLock("myLock");
這里你自己設(shè)置了加鎖的那個(gè)鎖key就是“myLock”。
ARGV[1]代表的就是鎖key的默認(rèn)生存時(shí)間，默認(rèn)30秒。
ARGV[2]代表的是加鎖的客戶端的ID，類似于下面這樣：
8743c9c0-0795-4907-87fd-6c719a6b4586:1
給大家解釋一下，第一段if判斷語句，就是用“exists myLock”命令判斷一下，如果你要加鎖的那個(gè)鎖key不存在的話，你就進(jìn)行加鎖。
如何加鎖呢？很簡單，用下面的命令：
hset myLock
8743c9c0-0795-4907-87fd-6c719a6b4586:1 1
通過這個(gè)命令設(shè)置一個(gè)hash數(shù)據(jù)結(jié)構(gòu)，這行命令執(zhí)行后，會(huì)出現(xiàn)一個(gè)類似下面的數(shù)據(jù)結(jié)構(gòu)：
上述就代表“8743c9c0-0795-4907-87fd-6c719a6b4586:1”這個(gè)客戶端對“myLock”這個(gè)鎖key完成了加鎖。
接著會(huì)執(zhí)行“pexpire myLock 30000”命令，設(shè)置myLock這個(gè)鎖key的生存時(shí)間是30秒。
好了，到此為止，ok，加鎖完成了。
（2）鎖互斥機(jī)制
那么在這個(gè)時(shí)候，如果客戶端2來嘗試加鎖，執(zhí)行了同樣的一段lua腳本，會(huì)咋樣呢？
很簡單，第一個(gè)if判斷會(huì)執(zhí)行“exists myLock”，發(fā)現(xiàn)myLock這個(gè)鎖key已經(jīng)存在了。
接著第二個(gè)if判斷，判斷一下，myLock鎖key的hash數(shù)據(jù)結(jié)構(gòu)中，是否包含客戶端2的ID，但是明顯不是的，因?yàn)槟抢锇氖强蛻舳?的ID。
所以，客戶端2會(huì)獲取到pttl myLock返回的一個(gè)數(shù)字，這個(gè)數(shù)字代表了myLock這個(gè)鎖key的剩余生存時(shí)間。比如還剩15000毫秒的生存時(shí)間。
此時(shí)客戶端2會(huì)進(jìn)入一個(gè)while循環(huán)，不停的嘗試加鎖。
（3）watch dog自動(dòng)延期機(jī)制
客戶端1加鎖的鎖key默認(rèn)生存時(shí)間才30秒，如果超過了30秒，客戶端1還想一直持有這把鎖，怎么辦呢？
簡單！只要客戶端1一旦加鎖成功，就會(huì)啟動(dòng)一個(gè)watch dog看門狗，他是一個(gè)后臺(tái)線程，會(huì)每隔10秒檢查一下，如果客戶端1還持有鎖key，那么就會(huì)不斷的延長鎖key的生存時(shí)間。
（4）可重入加鎖機(jī)制
那如果客戶端1都已經(jīng)持有了這把鎖了，結(jié)果可重入的加鎖會(huì)怎么樣呢？
比如下面這種代碼：
這時(shí)我們來分析一下上面那段lua腳本。
第一個(gè)if判斷肯定不成立，“exists myLock”會(huì)顯示鎖key已經(jīng)存在了。
第二個(gè)if判斷會(huì)成立，因?yàn)閙yLock的hash數(shù)據(jù)結(jié)構(gòu)中包含的那個(gè)ID，就是客戶端1的那個(gè)ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”
此時(shí)就會(huì)執(zhí)行可重入加鎖的邏輯，他會(huì)用：
incrby myLock
8743c9c0-0795-4907-87fd-6c71a6b4586:1 1
通過這個(gè)命令，對客戶端1的加鎖次數(shù)，累加1。
此時(shí)myLock數(shù)據(jù)結(jié)構(gòu)變?yōu)橄旅孢@樣：
大家看到了吧，那個(gè)myLock的hash數(shù)據(jù)結(jié)構(gòu)中的那個(gè)客戶端ID，就對應(yīng)著加鎖的次數(shù)
（5）釋放鎖機(jī)制
如果執(zhí)行l(wèi)ock.unlock()，就可以釋放分布式鎖，此時(shí)的業(yè)務(wù)邏輯也是非常簡單的。
其實(shí)說白了，就是每次都對myLock數(shù)據(jù)結(jié)構(gòu)中的那個(gè)加鎖次數(shù)減1。
如果發(fā)現(xiàn)加鎖次數(shù)是0了，說明這個(gè)客戶端已經(jīng)不再持有鎖了，此時(shí)就會(huì)用：
“del myLock”命令，從redis里刪除這個(gè)key。
然后呢，另外的客戶端2就可以嘗試完成加鎖了。
這就是所謂的分布式鎖的開源Redisson框架的實(shí)現(xiàn)機(jī)制。
一般我們在生產(chǎn)系統(tǒng)中，可以用Redisson框架提供的這個(gè)類庫來基于redis進(jìn)行分布式鎖的加鎖與釋放鎖。
（6）上述Redis分布式鎖的缺點(diǎn)
其實(shí)上面那種方案最大的問題，就是如果你對某個(gè)redis master實(shí)例，寫入了myLock這種鎖key的value，此時(shí)會(huì)異步復(fù)制給對應(yīng)的master slave實(shí)例。
但是這個(gè)過程中一旦發(fā)生redis master宕機(jī)，主備切換，redis slave變?yōu)榱藃edis master。
接著就會(huì)導(dǎo)致，客戶端2來嘗試加鎖的時(shí)候，在新的redis master上完成了加鎖，而客戶端1也以為自己成功加了鎖。
此時(shí)就會(huì)導(dǎo)致多個(gè)客戶端對一個(gè)分布式鎖完成了加鎖。
這時(shí)系統(tǒng)在業(yè)務(wù)語義上一定會(huì)出現(xiàn)問題，導(dǎo)致各種臟數(shù)據(jù)的產(chǎn)生。
所以這個(gè)就是redis cluster，或者是redis master-slave架構(gòu)的主從異步復(fù)制導(dǎo)致的redis分布式鎖的最大缺陷：在redis master實(shí)例宕機(jī)的時(shí)候，可能導(dǎo)致多個(gè)客戶端同時(shí)完成加鎖。
引用（本文章只供本人學(xué)習(xí)以及學(xué)習(xí)的記錄，如有侵權(quán)，請聯(lián)系我刪除）
拜托，面試請不要再問我Redis分布式鎖的實(shí)現(xiàn)原理
分布式鎖簡單入門以及三種實(shí)現(xiàn)方式介紹
Redis實(shí)現(xiàn)分布式鎖
