分布式鎖場(chǎng)景

• 互聯(lián)網(wǎng)秒殺
• 搶優(yōu)惠卷
• 接口冪等性校驗(yàn)

案例1

如下代碼模擬了下單減庫存的場(chǎng)景，我們分析下在高并發(fā)場(chǎng)景下會(huì)存在什么問題

package com.wangcp.redisson;import org.springframework.beans.factory.annotation.Autowired; import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController;@RestController public class IndexController {@Autowiredprivate StringRedisTemplate stringRedisTemplate;/*** 模擬下單減庫存的場(chǎng)景* @return*/@RequestMapping(value = "/duduct_stock")public String deductStock(){// 從redis 中拿當(dāng)前庫存的值int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));if(stock > 0){int realStock = stock - 1;stringRedisTemplate.opsForValue().set("stock",realStock + "");System.out.println("扣減成功，剩余庫存：" + realStock);}else{System.out.println("扣減失敗，庫存不足");}return "end";} }

假設(shè)在redis中庫存（stock）初始值是100。

現(xiàn)在有5個(gè)客戶端同時(shí)請(qǐng)求該接口，可能就會(huì)存在同時(shí)執(zhí)行

int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));

這行代碼，獲取到的值都為100，緊跟著判斷大于0后都進(jìn)行-1操作，最后設(shè)置到redis 中的值都為99。但正常執(zhí)行完成后redis中的值應(yīng)為 95。

案例2-使用synchronized 實(shí)現(xiàn)單機(jī)鎖

在遇到案例1的問題后，大部分人的第一反應(yīng)都會(huì)想到加鎖來控制事務(wù)的原子性，如下代碼所示：

@RequestMapping(value = "/duduct_stock") public String deductStock(){synchronized (this){// 從redis 中拿當(dāng)前庫存的值int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));if(stock > 0){int realStock = stock - 1;stringRedisTemplate.opsForValue().set("stock",realStock + "");System.out.println("扣減成功，剩余庫存：" + realStock);}else{System.out.println("扣減失敗，庫存不足");}}return "end"; }

現(xiàn)在當(dāng)有多個(gè)請(qǐng)求訪問該接口時(shí)，同一時(shí)刻只有一個(gè)請(qǐng)求可進(jìn)入方法體中進(jìn)行庫存的扣減，其余請(qǐng)求等候。

但我們都知道，synchronized 鎖是屬于JVM級(jí)別的，也就是我們俗稱的“單機(jī)鎖”。但現(xiàn)在基本大部分公司使用的都是集群部署，現(xiàn)在我們思考下以上代碼在集群部署的情況下還能保證庫存數(shù)據(jù)的一致性嗎？

答案是不能，如上圖所示，請(qǐng)求經(jīng)Nginx分發(fā)后，可能存在多個(gè)服務(wù)同時(shí)從Redis中獲取庫存數(shù)據(jù)，此時(shí)只加synchronized （單機(jī)鎖）是無效的，并發(fā)越高，出現(xiàn)問題的幾率就越大。

案例3-使用SETNX實(shí)現(xiàn)分布式鎖

setnx：將 key 的值設(shè)為 value，當(dāng)且僅當(dāng) key 不存在。

若給定 key 已經(jīng)存在，則 setnx 不做任何動(dòng)作。

使用setnx實(shí)現(xiàn)簡(jiǎn)單的分布式鎖：

/*** 模擬下單減庫存的場(chǎng)景* @return*/ @RequestMapping(value = "/duduct_stock") public String deductStock(){String lockKey = "product_001";// 使用 setnx 添加分布式鎖// 返回 true 代表之前redis中沒有key為 lockKey 的值，并已進(jìn)行成功設(shè)置// 返回 false 代表之前redis中已經(jīng)存在 lockKey 這個(gè)key了Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "wangcp");if(!result){// 代表已經(jīng)加鎖了return "error_code";}// 從redis 中拿當(dāng)前庫存的值int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));if(stock > 0){int realStock = stock - 1;stringRedisTemplate.opsForValue().set("stock",realStock + "");System.out.println("扣減成功，剩余庫存：" + realStock);}else{System.out.println("扣減失敗，庫存不足");}// 釋放鎖stringRedisTemplate.delete(lockKey);return "end"; }

我們知道 Redis 是單線程執(zhí)行，現(xiàn)在再看案例2中的流程圖時(shí)，哪怕高并發(fā)場(chǎng)景下多個(gè)請(qǐng)求都執(zhí)行到了setnx的代碼，redis會(huì)根據(jù)請(qǐng)求的先后順序進(jìn)行排列，只有排列在隊(duì)頭的請(qǐng)求才能設(shè)置成功。其它請(qǐng)求只能返回“error_code”。

當(dāng)setnx設(shè)置成功后，可執(zhí)行業(yè)務(wù)代碼對(duì)庫存扣減，執(zhí)行完成后對(duì)鎖進(jìn)行釋放。

我們?cè)賮硭伎枷乱陨洗a已經(jīng)完美實(shí)現(xiàn)分布式鎖了嗎？能夠支撐高并發(fā)場(chǎng)景嗎？答案并不是，上面的代碼還是存在很多問題的，離真正的分布式鎖還差的很遠(yuǎn)。我們分析下以上代碼存在的問題：

死鎖：假如第一個(gè)請(qǐng)求在setnx加鎖完成后，執(zhí)行業(yè)務(wù)代碼時(shí)出現(xiàn)了異常，那釋放鎖的代碼就無法執(zhí)行，后面所有的請(qǐng)求也都無法進(jìn)行操作了。

針對(duì)死鎖的問題，我們對(duì)代碼再次進(jìn)行優(yōu)化，添加try-finally，在finally中添加釋放鎖代碼，這樣無論如何都會(huì)執(zhí)行釋放鎖代碼，如下所示：

/*** 模擬下單減庫存的場(chǎng)景* @return*/ @RequestMapping(value = "/duduct_stock") public String deductStock(){String lockKey = "product_001";try{// 使用 setnx 添加分布式鎖// 返回 true 代表之前redis中沒有key為 lockKey 的值，并已進(jìn)行成功設(shè)置// 返回 false 代表之前redis中已經(jīng)存在 lockKey 這個(gè)key了Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "wangcp");if(!result){// 代表已經(jīng)加鎖了return "error_code";}// 從redis 中拿當(dāng)前庫存的值int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));if(stock > 0){int realStock = stock - 1;stringRedisTemplate.opsForValue().set("stock",realStock + "");System.out.println("扣減成功，剩余庫存：" + realStock);}else{System.out.println("扣減失敗，庫存不足");}}finally {// 釋放鎖stringRedisTemplate.delete(lockKey);}return "end"; }

經(jīng)過改進(jìn)后的代碼是否還存在問題呢？我們思考正常執(zhí)行的情況下應(yīng)該是沒有問題，但我們假設(shè)請(qǐng)求在執(zhí)行到業(yè)務(wù)代碼時(shí)服務(wù)突然宕機(jī)了，或者正巧你的運(yùn)維同事重新發(fā)版，粗暴的 kill -9 掉了呢，那代碼還能執(zhí)行 finally 嗎？

案例4-加入過期時(shí)間

針對(duì)想到的問題，對(duì)代碼再次進(jìn)行優(yōu)化，加入過期時(shí)間，這樣即便出現(xiàn)了上述的問題，在時(shí)間到期后鎖也會(huì)自動(dòng)釋放掉，不會(huì)出現(xiàn)“死鎖”的情況。

@RequestMapping(value = "/duduct_stock") public String deductStock(){String lockKey = "product_001";try{Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey,"wangcp",10,TimeUnit.SECONDS);if(!result){// 代表已經(jīng)加鎖了return "error_code";}// 從redis 中拿當(dāng)前庫存的值int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));if(stock > 0){int realStock = stock - 1;stringRedisTemplate.opsForValue().set("stock",realStock + "");System.out.println("扣減成功，剩余庫存：" + realStock);}else{System.out.println("扣減失敗，庫存不足");}}finally {// 釋放鎖stringRedisTemplate.delete(lockKey);}return "end"; }

現(xiàn)在我們?cè)偎伎家幌?#xff0c;給鎖加入過期時(shí)間后就可以了嗎？就可以完美運(yùn)行不出問題了嗎？

超時(shí)時(shí)間設(shè)置的10s真的合適嗎？如果不合適設(shè)置多少秒合適呢？如下圖所示

假設(shè)同一時(shí)間有三個(gè)請(qǐng)求。

請(qǐng)求1首先加鎖后需執(zhí)行15秒，但在執(zhí)行到10秒時(shí)鎖失效釋放。

請(qǐng)求2進(jìn)入后加鎖執(zhí)行，在請(qǐng)求2執(zhí)行到5秒時(shí)，請(qǐng)求1執(zhí)行完成進(jìn)行鎖釋放，但此時(shí)釋放掉的是請(qǐng)求2的鎖。

請(qǐng)求3在請(qǐng)求2執(zhí)行5秒時(shí)開始執(zhí)行，但在執(zhí)行到3秒時(shí)請(qǐng)求2執(zhí)行完成將請(qǐng)求3的鎖進(jìn)行釋放。

我們現(xiàn)在只是模擬3個(gè)請(qǐng)求便可看出問題，如果在真正高并發(fā)的場(chǎng)景下，可能鎖就會(huì)面臨“一直失效”或“永久失效”。

那么具體問題出在哪里呢？總結(jié)為以下幾點(diǎn)：

• 1.存在請(qǐng)求釋放鎖時(shí)釋放掉的并不是自己的鎖
• 2.超時(shí)時(shí)間過短，存在代碼未執(zhí)行完便自動(dòng)釋放

針對(duì)問題我們思考對(duì)應(yīng)的解決方法：

• 針對(duì)問題1，我們想到在請(qǐng)求進(jìn)入時(shí)生成一個(gè)唯一id，使用該唯一id作為鎖的value值，釋放時(shí)先進(jìn)行獲取比對(duì)，比對(duì)相同時(shí)再進(jìn)行釋放，這樣就可以解決釋放掉其它請(qǐng)求鎖的問題。
• 針對(duì)問題2，我們思考不斷的延長(zhǎng)過期時(shí)間真的合適嗎？設(shè)置短了存在超時(shí)自動(dòng)釋放的問題，設(shè)置長(zhǎng)了又會(huì)出現(xiàn)宕機(jī)后一段時(shí)間鎖無法釋放的問題，雖然不會(huì)再出現(xiàn)“死鎖”。針對(duì)這個(gè)問題，如何解決呢？

案例5-Redisson分布式鎖

SpringBoot集成Redisson步驟

引入依賴

<dependency><groupId>org.redisson</groupId><artifactId>redisson</artifactId><version>3.6.5</version> </dependency>

初始化客戶端

@Bean public RedissonClient redisson(){// 單機(jī)模式Config config = new Config();config.useSingleServer().setAddress("redis://192.168.3.170:6379").setDatabase(0);return Redisson.create(config); }

Redisson實(shí)現(xiàn)分布式鎖

package com.wangcp.redisson;import org.redisson.api.RLock; import org.redisson.api.RedissonClient; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController;@RestController public class IndexController {@Autowiredprivate RedissonClient redisson;@Autowiredprivate StringRedisTemplate stringRedisTemplate;/*** 模擬下單減庫存的場(chǎng)景* @return*/@RequestMapping(value = "/duduct_stock")public String deductStock(){String lockKey = "product_001";// 1.獲取鎖對(duì)象RLock redissonLock = redisson.getLock(lockKey);try{// 2.加鎖redissonLock.lock(); // 等價(jià)于 setIfAbsent(lockKey,"wangcp",10,TimeUnit.SECONDS);// 從redis 中拿當(dāng)前庫存的值int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));if(stock > 0){int realStock = stock - 1;stringRedisTemplate.opsForValue().set("stock",realStock + "");System.out.println("扣減成功，剩余庫存：" + realStock);}else{System.out.println("扣減失敗，庫存不足");}}finally {// 3.釋放鎖redissonLock.unlock();}return "end";} }

Redisson 分布式鎖實(shí)現(xiàn)原理圖

Redisson 底層源碼分析

我們點(diǎn)擊 lock() 方法，查看源碼，最終看到以下代碼

<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {internalLockLeaseTime = unit.toMillis(leaseTime);return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,"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 redis.call('pttl', KEYS[1]);",Collections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));}

沒錯(cuò)，加鎖最終執(zhí)行的就是這段 lua 腳本語言。

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;

腳本的主要邏輯為：

• exists 判斷 key 是否存在
• 當(dāng)判斷不存在則設(shè)置 key
• 然后給設(shè)置的key追加過期時(shí)間

這樣來看其實(shí)和我們前面案例中的實(shí)現(xiàn)方法好像沒什么區(qū)別，但實(shí)際上并不是。

這段lua腳本命令在Redis中執(zhí)行時(shí)，會(huì)被當(dāng)成一條命令來執(zhí)行，能夠保證原子性，故要不都成功，要不都失敗。

我們?cè)谠创a中看到Redssion的許多方法實(shí)現(xiàn)中很多都用到了lua腳本，這樣能夠極大的保證命令執(zhí)行的原子性。

Redisson鎖自動(dòng)“續(xù)命”源碼

private void scheduleExpirationRenewal(final long threadId) {if (expirationRenewalMap.containsKey(getEntryName())) {return;}Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {@Overridepublic void run(Timeout timeout) throws Exception {RFuture<Boolean> future = commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +"redis.call('pexpire', KEYS[1], ARGV[1]); " +"return 1; " +"end; " +"return 0;",Collections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));future.addListener(new FutureListener<Boolean>() {@Overridepublic void operationComplete(Future<Boolean> future) throws Exception {expirationRenewalMap.remove(getEntryName());if (!future.isSuccess()) {log.error("Can't update lock " + getName() + " expiration", future.cause());return;}if (future.getNow()) {// reschedule itselfscheduleExpirationRenewal(threadId);}}});}}, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);if (expirationRenewalMap.putIfAbsent(getEntryName(), task) != null) {task.cancel();} }

這段代碼是在加鎖后開啟一個(gè)守護(hù)線程進(jìn)行監(jiān)聽。Redisson超時(shí)時(shí)間默認(rèn)設(shè)置30s，線程每10s調(diào)用一次判斷鎖還是否存在，如果存在則延長(zhǎng)鎖的超時(shí)時(shí)間。

現(xiàn)在，我們?cè)倩剡^頭來看看案例5中的加鎖代碼與原理圖，其實(shí)完善到這種程度已經(jīng)可以滿足很多公司的使用了，并且很多公司也確實(shí)是這樣用的。但我們?cè)偎伎枷率欠襁€存在問題呢？例如以下場(chǎng)景：

• 眾所周知 Redis 在實(shí)際部署使用時(shí)都是集群部署的，那在高并發(fā)場(chǎng)景下我們加鎖，當(dāng)把key寫入到master節(jié)點(diǎn)后，master還未同步到slave節(jié)點(diǎn)時(shí)master宕機(jī)了，原有的slave節(jié)點(diǎn)經(jīng)過選舉變?yōu)榱诵碌膍aster節(jié)點(diǎn)，此時(shí)可能就會(huì)出現(xiàn)鎖失效問題。
• 通過分布式鎖的實(shí)現(xiàn)機(jī)制我們知道，高并發(fā)場(chǎng)景下只有加鎖成功的請(qǐng)求可以繼續(xù)處理業(yè)務(wù)邏輯。那就出現(xiàn)了大伙都來加鎖，但有且僅有一個(gè)加鎖成功了，剩余的都在等待。其實(shí)分布式鎖與高并發(fā)在語義上就是相違背的，我們的請(qǐng)求雖然都是并發(fā)，但Redis幫我們把請(qǐng)求進(jìn)行了排隊(duì)執(zhí)行，也就是把我們的并行轉(zhuǎn)為了串行。串行執(zhí)行的代碼肯定不存在并發(fā)問題了，但是程序的性能肯定也會(huì)因此受到影響。

針對(duì)這些問題，我們?cè)俅嗡伎冀鉀Q方案

• 在思考解決方案時(shí)我們首先想到CAP原則（一致性、可用性、分區(qū)容錯(cuò)性），那么現(xiàn)在的Redis就是滿足AP(可用性、分區(qū)容錯(cuò)性)，如果想要解決該問題我們就需要尋找滿足CP(一致性、分區(qū)容錯(cuò)性)的分布式系統(tǒng)。首先想到的就是zookeeper，zookeeper的集群間數(shù)據(jù)同步機(jī)制是當(dāng)主節(jié)點(diǎn)接收數(shù)據(jù)后不會(huì)立即返回給客戶端成功的反饋，它會(huì)先與子節(jié)點(diǎn)進(jìn)行數(shù)據(jù)同步，半數(shù)以上的節(jié)點(diǎn)都完成同步后才會(huì)通知客戶端接收成功。并且如果主節(jié)點(diǎn)宕機(jī)后，根據(jù)zookeeper的Zab協(xié)議（Zookeeper原子廣播）重新選舉的主節(jié)點(diǎn)一定是已經(jīng)同步成功的。那么問題來了，Redisson與zookeeper分布式鎖我們?nèi)绾芜x擇呢？答案是如果并發(fā)量沒有那么高，可以用zookeeper來做分布式鎖，但是它的并發(fā)能力遠(yuǎn)遠(yuǎn)不如Redis。如果你對(duì)并發(fā)要求比較高的話，那就用Redis，偶爾出現(xiàn)的主從架構(gòu)鎖失效的問題其實(shí)是可以容忍的。
• 關(guān)于第二個(gè)提升性能的問題，我們可以參考ConcurrentHashMap的鎖分段技術(shù)的思想，例如我們代碼的庫存量當(dāng)前為1000，那我們可以分為10段，每段100，然后對(duì)每段分別加鎖，這樣就可以同時(shí)執(zhí)行10個(gè)請(qǐng)求的加鎖與處理，當(dāng)然有要求的同學(xué)還可以繼續(xù)細(xì)分。但其實(shí)Redis的Qps已經(jīng)達(dá)到10W+了，沒有特別高并發(fā)量的場(chǎng)景下也是完全夠用的。

總結(jié)

以上是生活随笔為你收集整理的分布式锁（Redisson）-从零开始，深入理解与不断优化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。