您好,登錄后才能下訂單哦!
本文小編為大家詳細介紹“Redisson的原理是什么”,內(nèi)容詳細,步驟清晰,細節(jié)處理妥當,希望這篇“Redisson的原理是什么”文章能幫助大家解決疑惑,下面跟著小編的思路慢慢深入,一起來學習新知識吧。
互聯(lián)網(wǎng)秒殺
搶優(yōu)惠卷
接口冪等性校驗
如下代碼模擬了下單減庫存的場景,我們分析下在高并發(fā)場景下會存在什么問題
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 { @Autowired private StringRedisTemplate stringRedisTemplate; /** * 模擬下單減庫存的場景 * @return */ @RequestMapping(value = "/duduct_stock") public String deductStock(){ // 從redis 中拿當前庫存的值 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個客戶端同時請求該接口,可能就會存在同時執(zhí)行
int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
這行代碼,獲取到的值都為100,緊跟著判斷大于0后都進行-1操作,最后設(shè)置到redis 中的值都為99。但正常執(zhí)行完成后redis中的值應為 95。
在遇到案例1的問題后,大部分人的第一反應都會想到加鎖來控制事務(wù)的原子性,如下代碼所示:
@RequestMapping(value = "/duduct_stock") public String deductStock(){ synchronized (this){ // 從redis 中拿當前庫存的值 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)在當有多個請求訪問該接口時,同一時刻只有一個請求可進入方法體中進行庫存的扣減,其余請求等候。
但我們都知道,synchronized 鎖是屬于JVM級別的,也就是我們俗稱的“單機鎖”。但現(xiàn)在基本大部分公司使用的都是集群部署,現(xiàn)在我們思考下以上代碼在集群部署的情況下還能保證庫存數(shù)據(jù)的一致性嗎?
答案是不能,如上圖所示,請求經(jīng)Nginx分發(fā)后,可能存在多個服務(wù)同時從Redis中獲取庫存數(shù)據(jù),此時只加synchronized (單機鎖)是無效的,并發(fā)越高,出現(xiàn)問題的幾率就越大。
setnx:將 key 的值設(shè)為 value,當且僅當 key 不存在。
若給定 key 已經(jīng)存在,則 setnx 不做任何動作。
使用setnx實現(xiàn)簡單的分布式鎖:
/** * 模擬下單減庫存的場景 * @return */ @RequestMapping(value = "/duduct_stock") public String deductStock(){ String lockKey = "product_001"; // 使用 setnx 添加分布式鎖 // 返回 true 代表之前redis中沒有key為 lockKey 的值,并已進行成功設(shè)置 // 返回 false 代表之前redis中已經(jīng)存在 lockKey 這個key了 Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "wangcp"); if(!result){ // 代表已經(jīng)加鎖了 return "error_code"; } // 從redis 中拿當前庫存的值 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中的流程圖時,哪怕高并發(fā)場景下多個請求都執(zhí)行到了setnx的代碼,redis會根據(jù)請求的先后順序進行排列,只有排列在隊頭的請求才能設(shè)置成功。其它請求只能返回“error_code”。
當setnx設(shè)置成功后,可執(zhí)行業(yè)務(wù)代碼對庫存扣減,執(zhí)行完成后對鎖進行釋放。
我們再來思考下以上代碼已經(jīng)完美實現(xiàn)分布式鎖了嗎?能夠支撐高并發(fā)場景嗎?答案并不是,上面的代碼還是存在很多問題的,離真正的分布式鎖還差的很遠。我們分析下以上代碼存在的問題:
死鎖:假如第一個請求在setnx加鎖完成后,執(zhí)行業(yè)務(wù)代碼時出現(xiàn)了異常,那釋放鎖的代碼就無法執(zhí)行,后面所有的請求也都無法進行操作了。
針對死鎖的問題,我們對代碼再次進行優(yōu)化,添加try-finally,在finally中添加釋放鎖代碼,這樣無論如何都會執(zhí)行釋放鎖代碼,如下所示:
/** * 模擬下單減庫存的場景 * @return */ @RequestMapping(value = "/duduct_stock") public String deductStock(){ String lockKey = "product_001"; try{ // 使用 setnx 添加分布式鎖 // 返回 true 代表之前redis中沒有key為 lockKey 的值,并已進行成功設(shè)置 // 返回 false 代表之前redis中已經(jīng)存在 lockKey 這個key了 Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "wangcp"); if(!result){ // 代表已經(jīng)加鎖了 return "error_code"; } // 從redis 中拿當前庫存的值 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)過改進后的代碼是否還存在問題呢?我們思考正常執(zhí)行的情況下應該是沒有問題,但我們假設(shè)請求在執(zhí)行到業(yè)務(wù)代碼時服務(wù)突然宕機了,或者正巧你的運維同事重新發(fā)版,粗暴的 kill -9 掉了呢,那代碼還能執(zhí)行 finally 嗎?
針對想到的問題,對代碼再次進行優(yōu)化,加入過期時間,這樣即便出現(xiàn)了上述的問題,在時間到期后鎖也會自動釋放掉,不會出現(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 中拿當前庫存的值 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)在我們再思考一下,給鎖加入過期時間后就可以了嗎?就可以完美運行不出問題了嗎?
超時時間設(shè)置的10s真的合適嗎?如果不合適設(shè)置多少秒合適呢?
假設(shè)同一時間有三個請求。
請求1首先加鎖后需執(zhí)行15秒,但在執(zhí)行到10秒時鎖失效釋放。
請求2進入后加鎖執(zhí)行,在請求2執(zhí)行到5秒時,請求1執(zhí)行完成進行鎖釋放,但此時釋放掉的是請求2的鎖。
請求3在請求2執(zhí)行5秒時開始執(zhí)行,但在執(zhí)行到3秒時請求2執(zhí)行完成將請求3的鎖進行釋放。
我們現(xiàn)在只是模擬3個請求便可看出問題,如果在真正高并發(fā)的場景下,可能鎖就會面臨“一直失效”或“永久失效”。
那么具體問題出在哪里呢?總結(jié)為以下幾點:
1.存在請求釋放鎖時釋放掉的并不是自己的鎖
2.超時時間過短,存在代碼未執(zhí)行完便自動釋放
針對問題我們思考對應的解決方法:
針對問題1,我們想到在請求進入時生成一個唯一id,使用該唯一id作為鎖的value值,釋放時先進行獲取比對,比對相同時再進行釋放,這樣就可以解決釋放掉其它請求鎖的問題。
針對問題2,我們可使用延長過期時間。
針對想到的問題,對代碼再次進行優(yōu)化,使用唯一id作為鎖的value值,這樣便不存在請求釋放鎖時釋放掉的并不是自己的鎖。
@RequestMapping(value = "/duduct_stock") public String deductStock(){ String lockKey = "product_001"; try{ //1、占分布式鎖。去redis占坑并設(shè)置過期時間 setIfAbsent()操作是原子性的 final String uuid = UUID.randomUUID().toString(); Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey,uuid,30,TimeUnit.SECONDS); if(!result){ // 代表已經(jīng)加鎖了 return "error_code"; } // 從redis 中拿當前庫存的值 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 { // 釋放鎖 使用lua腳本解鎖 保證原子性 String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end"; stringRedisTemplate.execute(new DefaultRedisScript<Long>(script, Long.class), Arrays.asList(lockKey), uuid); } return "end"; }
但是我們思考一下,不斷的延長過期時間真的合適嗎?設(shè)置短了存在超時自動釋放的問題,設(shè)置長了又會出現(xiàn)宕機后一段時間鎖無法釋放的問題,雖然不會再出現(xiàn)“死鎖”。針對這個問題,如何解決呢?
我們應該要開啟一個守護線程進行監(jiān)聽。將超時時間設(shè)置默認30s,線程每10s調(diào)用一次判斷鎖還是否存在,如果存在則延長鎖的超時時間。
SpringBoot集成Redisson步驟
引入依賴
<dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> <version>3.6.5</version> </dependency>
初始化客戶端
@Bean public RedissonClient redisson(){ // 單機模式 Config config = new Config(); config.useSingleServer().setAddress("redis://192.168.3.170:6379").setDatabase(0); return Redisson.create(config); }
Redisson實現(xiàn)分布式鎖
@RestController public class IndexController { @Autowired private RedissonClient redisson; @Autowired private StringRedisTemplate stringRedisTemplate; /** * 模擬下單減庫存的場景 * @return */ @RequestMapping(value = "/duduct_stock") public String deductStock(){ String lockKey = "product_001"; // 1.獲取鎖對象 RLock redissonLock = redisson.getLock(lockKey); try{ // 2.加鎖 redissonLock.lock(); // 等價于 setIfAbsent(lockKey,"wangcp",10,TimeUnit.SECONDS); // 從redis 中拿當前庫存的值 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 分布式鎖實現(xiàn)原理圖
Redisson 底層源碼分析
我們點擊 lock() 和 unlock() 方法,查看源碼,最終看到以下代碼
//加鎖 <T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) { return evalWriteAsync(getRawName(), LongCodec.INSTANCE, command, "if (redis.call('exists', KEYS[1]) == 0) then " + "redis.call('hincrby', 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.singletonList(getRawName()), unit.toMillis(leaseTime), getLockName(threadId)); } //解鎖 protected RFuture<Boolean> unlockInnerAsync(long threadId) { return evalWriteAsync(getRawName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN, "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 " + "redis.call('pexpire', KEYS[1], ARGV[2]); " + "return 0; " + "else " + "redis.call('del', KEYS[1]); " + "redis.call('publish', KEYS[2], ARGV[1]); " + "return 1; " + "end; " + "return nil;", Arrays.asList(getRawName(), getChannelName()), LockPubSub.UNLOCK_MESSAGE, internalLockLeaseTime, getLockName(threadId)); }
沒錯,加鎖最終執(zhí)行的就是這段 lua 腳本語言。
這段lua腳本命令在Redis中執(zhí)行時,會被當成一條命令來執(zhí)行,能夠保證原子性,故要不都成功,要不都失敗。
我們在源碼中看到Redssion的許多方法實現(xiàn)中很多都用到了lua腳本,這樣能夠極大的保證命令執(zhí)行的原子性。
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 是否存在
當判斷不存在則設(shè)置 key
然后給設(shè)置的key追加過期時間
這樣來看其實和我們前面案例5中的實現(xiàn)方法本質(zhì)沒啥區(qū)別,都是使用底層都是lua。只不過redisson做了更多的判斷,考慮的更加的周全。而且他還完善了我們案例5中的缺陷,他實現(xiàn)了一個看門狗機制。
Redisson鎖"看門狗"源碼
private void renewExpiration() { ExpirationEntry ee = EXPIRATION_RENEWAL_MAP.get(getEntryName()); if (ee == null) { return; } Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() { @Override public void run(Timeout timeout) throws Exception { ExpirationEntry ent = EXPIRATION_RENEWAL_MAP.get(getEntryName()); if (ent == null) { return; } Long threadId = ent.getFirstThreadId(); if (threadId == null) { return; } RFuture<Boolean> future = renewExpirationAsync(threadId); future.onComplete((res, e) -> { if (e != null) { log.error("Can't update lock " + getRawName() + " expiration", e); EXPIRATION_RENEWAL_MAP.remove(getEntryName()); return; } if (res) { // reschedule itself renewExpiration(); } else { cancelExpirationRenewal(null); } }); } }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS); ee.setTimeout(task); } protected RFuture<Boolean> renewExpirationAsync(long threadId) { return evalWriteAsync(getRawName(), 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.singletonList(getRawName()), internalLockLeaseTime, getLockName(threadId)); }
這段代碼是在加鎖后開啟一個守護線程進行監(jiān)聽。Redisson超時時間默認設(shè)置30s,線程每10s調(diào)用一次判斷鎖還是否存在,如果存在則延長鎖的超時時間。
現(xiàn)在,我們再回過頭來看看案例5中的加鎖代碼與原理圖,其實完善到這種程度已經(jīng)可以滿足很多公司的使用了,并且很多公司也確實是這樣用的。但我們再思考下是否還存在問題呢?例如以下場景:
眾所周知 Redis 在實際部署使用時都是集群部署的,那在高并發(fā)場景下我們加鎖,當把key寫入到master節(jié)點后,master還未同步到slave節(jié)點時master宕機了,原有的slave節(jié)點經(jīng)過選舉變?yōu)榱诵碌膍aster節(jié)點,此時可能就會出現(xiàn)鎖失效問題。
通過分布式鎖的實現(xiàn)機制我們知道,高并發(fā)場景下只有加鎖成功的請求可以繼續(xù)處理業(yè)務(wù)邏輯。那就出現(xiàn)了大伙都來加鎖,但有且僅有一個加鎖成功了,剩余的都在等待。其實分布式鎖與高并發(fā)在語義上就是相違背的,我們的請求雖然都是并發(fā),但Redis幫我們把請求進行了排隊執(zhí)行,也就是把我們的并行轉(zhuǎn)為了串行。串行執(zhí)行的代碼肯定不存在并發(fā)問題了,但是程序的性能肯定也會因此受到影響。
針對這些問題,我們再次思考解決方案
在思考解決方案時我們首先想到CAP原則(一致性、可用性、分區(qū)容錯性),那么現(xiàn)在的Redis就是滿足AP(可用性、分區(qū)容錯性),如果想要解決該問題我們就需要尋找滿足CP(一致性、分區(qū)容錯性)的分布式系統(tǒng)。首先想到的就是zookeeper,zookeeper的集群間數(shù)據(jù)同步機制是當主節(jié)點接收數(shù)據(jù)后不會立即返回給客戶端成功的反饋,它會先與子節(jié)點進行數(shù)據(jù)同步,半數(shù)以上的節(jié)點都完成同步后才會通知客戶端接收成功。并且如果主節(jié)點宕機后,根據(jù)zookeeper的Zab協(xié)議(Zookeeper原子廣播)重新選舉的主節(jié)點一定是已經(jīng)同步成功的。
那么問題來了,Redisson與zookeeper分布式鎖我們?nèi)绾芜x擇呢?答案是如果并發(fā)量沒有那么高,可以用zookeeper來做分布式鎖,但是它的并發(fā)能力遠遠不如Redis。如果你對并發(fā)要求比較高的話,那就用Redis,偶爾出現(xiàn)的主從架構(gòu)鎖失效的問題其實是可以容忍的。
關(guān)于第二個提升性能的問題,我們可以參考ConcurrentHashMap的鎖分段技術(shù)的思想,例如我們代碼的庫存量當前為1000,那我們可以分為10段,每段100,然后對每段分別加鎖,這樣就可以同時執(zhí)行10個請求的加鎖與處理,當然有要求的同學還可以繼續(xù)細分。但其實Redis的Qps已經(jīng)達到10W+了,沒有特別高并發(fā)量的場景下也是完全夠用的。
讀到這里,這篇“Redisson的原理是什么”文章已經(jīng)介紹完畢,想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領(lǐng)會,如果想了解更多相關(guān)內(nèi)容的文章,歡迎關(guān)注億速云行業(yè)資訊頻道。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。