建站
咨詢
售后
建站咨詢
新聞中心
Redis分布式鎖的原理是什么？如何續(xù)期？
分布式鎖的需求產(chǎn)生
分布式鎖的需求是伴隨著應(yīng)用分布式部署而來的，在單體應(yīng)用，且只部署一臺(tái)服務(wù)器的情況下，通過java的同步鎖即可實(shí)現(xiàn)。同步鎖，即是一個(gè)原子性的操作。
那么當(dāng)應(yīng)用進(jìn)行了分布式部署，應(yīng)用有多個(gè)服務(wù)，這個(gè)時(shí)候應(yīng)用服務(wù)端就沒有一個(gè)可提供原子性操作的地方了，Redis性能高，且是單線程，因此可提供一個(gè)原子性操作的地方，利用它，就可以實(shí)現(xiàn)分布式鎖。
用場(chǎng)景說話，使用Redis分布式鎖的場(chǎng)景如下圖所示：
如下圖所示，隨后會(huì)根據(jù)場(chǎng)景說明分布式鎖及續(xù)期相關(guān)問題的來龍去脈。
- 圖中序號(hào)1：進(jìn)來一個(gè)請(qǐng)求，這個(gè)請(qǐng)求要求我們保存一個(gè)“訂單A”；
- 圖中序號(hào)2：2.1 步，請(qǐng)求進(jìn)來，首先去嘗試設(shè)置一個(gè)Redis 值，他的鍵就是訂單號(hào)“訂單A”，如果嘗試成功，則代表我這個(gè)線程是第一次設(shè)置，相當(dāng)于我拿到了這個(gè)鎖；如果嘗試失敗，那么，可以拋出異常或者等待一段時(shí)候后再次重試，這里可以根據(jù)業(yè)務(wù)場(chǎng)景的不同采取不同的策略。這里的關(guān)鍵是在Redis中的操作是單線程的，因此該操作是原子性的。2.2步，為了防止應(yīng)用服務(wù)意外中斷，Redis中的數(shù)據(jù)一直存活，消耗資源，需要設(shè)置一個(gè)超時(shí)時(shí)間。（如果為了嚴(yán)謹(jǐn)，可以將2.1, 2.2 兩步封裝成一個(gè)lua腳本部署在Redis服務(wù)器上）
- 圖中序號(hào)3：情況A，這個(gè)時(shí)候是當(dāng)Redis的key還未失效，程序就已經(jīng)執(zhí)行完成，且刪除了Redis中的數(shù)據(jù)，一切正常；情況B：就是需要續(xù)期的場(chǎng)景，如果要避免這個(gè)場(chǎng)景的出現(xiàn)，可以將Redis key的失效時(shí)間設(shè)置長(zhǎng)一點(diǎn)，可以應(yīng)對(duì)大多數(shù)業(yè)務(wù)。如果要徹底解決，可以在應(yīng)用端添加一個(gè)Redis鎖的注冊(cè)中心，然后起一個(gè)監(jiān)聽線程去監(jiān)聽這個(gè)注冊(cè)中心，發(fā)現(xiàn)有鎖還在被持有，但是Redis 已經(jīng)快過期了，則修改相應(yīng)key的失效時(shí)間，進(jìn)行續(xù)期。
在傳統(tǒng)單體應(yīng)用單機(jī)部署的情況下，并發(fā)問題可以通過使用Java并發(fā)相關(guān)的鎖如synchronized，但是當(dāng)規(guī)模上升到分布式集群的情況下，要控制共享資源訪問，就需要通過分布式鎖來實(shí)現(xiàn)。常見的分布式鎖方案如數(shù)據(jù)庫(kù)樂觀鎖，Redis鎖，zk鎖等。
Redis分布式鎖可以有多種方式實(shí)現(xiàn)但是其核心就是通過以下三個(gè)Redis命令組合實(shí)現(xiàn)。
上面為Redis的一個(gè)最簡(jiǎn)單的鎖實(shí)現(xiàn)原理，實(shí)際中還需要考慮更多具體的情況作出相應(yīng)的調(diào)整。如
實(shí)際開發(fā)環(huán)境中不確定的因素有很多，需要慢慢地去調(diào)整實(shí)踐達(dá)到理想狀態(tài)，可以考慮使用redisson框架來實(shí)現(xiàn)。
這個(gè)情況比較獨(dú)特，出現(xiàn)這個(gè)問題的根本原因在于鎖失效的時(shí)間小于業(yè)務(wù)處理的時(shí)間導(dǎo)致業(yè)務(wù)還沒處理完畢鎖就釋放了。那么解決方案是合理地結(jié)合業(yè)務(wù)去設(shè)置鎖失效的時(shí)間。
但是也有更好的方案就如前文提到的redisson，其中的可重入鎖概念。
默認(rèn)情況下,加鎖的時(shí)間是30秒.如果加鎖的業(yè)務(wù)沒有執(zhí)行完,那么到 30-10 = 20秒的時(shí)候,就會(huì)進(jìn)行一次續(xù)期,把鎖重置成30秒。
什么時(shí)候需要分布式鎖？
作為BAT的Java web開發(fā)工程師來回答這個(gè)問題。
分布式鎖是目前Java web開發(fā)過程中常見的一個(gè)情況，接下來，我從場(chǎng)景以及如何實(shí)現(xiàn)兩個(gè)維度來分析。
當(dāng)你的后端服務(wù)是以集群形式存在的時(shí)候，是一定需要分布式鎖的。集群與分布式不同，而這里的分布式與分布式鎖也不是同一回事兒。集群可以指多臺(tái)服務(wù)器實(shí)現(xiàn)了同樣的需求，比如有三臺(tái)Tomcat，都負(fù)責(zé)查詢模塊；而分布式指多臺(tái)服務(wù)器各自不同的功能點(diǎn)，多臺(tái)功能的整合對(duì)外是一個(gè)完整的服務(wù)，比如一臺(tái)Tomcat負(fù)責(zé)查詢，一臺(tái)負(fù)責(zé)下單。
說回集群，當(dāng)后端集群要去訪問同一個(gè)資源的時(shí)候，就需要對(duì)該資源加鎖，保證同一時(shí)刻只能有一個(gè)對(duì)象來修改該資源數(shù)據(jù)，如果不加鎖會(huì)導(dǎo)致什么情況呢？
舉一個(gè)例子：
有兩個(gè)線程（分別叫T1,T2）做的都是同樣的事情，拿到一個(gè)叫做A的資源，然后對(duì)其進(jìn)行+1操作。由于線程之間是不會(huì)互相通信的，于是就有可能出現(xiàn)下面這種情況：
T1拿到A，讀入內(nèi)存，此時(shí)A值為T；
T2拿到A，讀入內(nèi)存，此時(shí)A值為T；
T1進(jìn)行+1操作，此時(shí)A實(shí)際值為T+1；
到此，以上就是小編對(duì)于redis分布式鎖失效問題的問題就介紹到這了，希望這2點(diǎn)解答對(duì)大家有用。
文章標(biāo)題：Redis分布式鎖的原理是什么？如何續(xù)期？（redis分布式鎖發(fā)生死鎖怎么解決）
URL地址：http://m.5511xx.com/article/dpsjpso.html
