建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
Redis分布式鎖的原理是什么？如何續(xù)期？
在傳統(tǒng)單體應(yīng)用單機(jī)部署的情況下，并發(fā)問(wèn)題可以通過(guò)使用Java并發(fā)相關(guān)的鎖如synchronized，但是當(dāng)規(guī)模上升到分布式集群的情況下，要控制共享資源訪(fǎng)問(wèn)，就需要通過(guò)分布式鎖來(lái)實(shí)現(xiàn)。常見(jiàn)的分布式鎖方案如數(shù)據(jù)庫(kù)樂(lè)觀鎖，Redis鎖，zk鎖等。
公司主營(yíng)業(yè)務(wù)：成都網(wǎng)站建設(shè)、成都做網(wǎng)站、移動(dòng)網(wǎng)站開(kāi)發(fā)等業(yè)務(wù)。幫助企業(yè)客戶(hù)真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開(kāi)放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶(hù)帶來(lái)驚喜。成都創(chuàng)新互聯(lián)公司推出云安免費(fèi)做網(wǎng)站回饋大家。
Redis分布式鎖可以有多種方式實(shí)現(xiàn)但是其核心就是通過(guò)以下三個(gè)Redis命令組合實(shí)現(xiàn)。
上面為Redis的一個(gè)最簡(jiǎn)單的鎖實(shí)現(xiàn)原理，實(shí)際中還需要考慮更多具體的情況作出相應(yīng)的調(diào)整。如
實(shí)際開(kāi)發(fā)環(huán)境中不確定的因素有很多，需要慢慢地去調(diào)整實(shí)踐達(dá)到理想狀態(tài)，可以考慮使用redisson框架來(lái)實(shí)現(xiàn)。
這個(gè)情況比較獨(dú)特，出現(xiàn)這個(gè)問(wèn)題的根本原因在于鎖失效的時(shí)間小于業(yè)務(wù)處理的時(shí)間導(dǎo)致業(yè)務(wù)還沒(méi)處理完畢鎖就釋放了。那么解決方案是合理地結(jié)合業(yè)務(wù)去設(shè)置鎖失效的時(shí)間。
但是也有更好的方案就如前文提到的redisson，其中的可重入鎖概念。
默認(rèn)情況下,加鎖的時(shí)間是30秒.如果加鎖的業(yè)務(wù)沒(méi)有執(zhí)行完,那么到 30-10 = 20秒的時(shí)候,就會(huì)進(jìn)行一次續(xù)期,把鎖重置成30秒。
分布式鎖的需求產(chǎn)生
分布式鎖的需求是伴隨著應(yīng)用分布式部署而來(lái)的，在單體應(yīng)用，且只部署一臺(tái)服務(wù)器的情況下，通過(guò)java的同步鎖即可實(shí)現(xiàn)。同步鎖，即是一個(gè)原子性的操作。
那么當(dāng)應(yīng)用進(jìn)行了分布式部署，應(yīng)用有多個(gè)服務(wù)，這個(gè)時(shí)候應(yīng)用服務(wù)端就沒(méi)有一個(gè)可提供原子性操作的地方了，Redis性能高，且是單線(xiàn)程，因此可提供一個(gè)原子性操作的地方，利用它，就可以實(shí)現(xiàn)分布式鎖。
用場(chǎng)景說(shuō)話(huà)，使用Redis分布式鎖的場(chǎng)景如下圖所示：
如下圖所示，隨后會(huì)根據(jù)場(chǎng)景說(shuō)明分布式鎖及續(xù)期相關(guān)問(wèn)題的來(lái)龍去脈。
- 圖中序號(hào)1：進(jìn)來(lái)一個(gè)請(qǐng)求，這個(gè)請(qǐng)求要求我們保存一個(gè)“訂單A”；
- 圖中序號(hào)2：2.1 步，請(qǐng)求進(jìn)來(lái)，首先去嘗試設(shè)置一個(gè)Redis 值，他的鍵就是訂單號(hào)“訂單A”，如果嘗試成功，則代表我這個(gè)線(xiàn)程是第一次設(shè)置，相當(dāng)于我拿到了這個(gè)鎖；如果嘗試失敗，那么，可以?huà)伋霎惓；蛘叩却欢螘r(shí)候后再次重試，這里可以根據(jù)業(yè)務(wù)場(chǎng)景的不同采取不同的策略。這里的關(guān)鍵是在Redis中的操作是單線(xiàn)程的，因此該操作是原子性的。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)聽(tīng)線(xiàn)程去監(jiān)聽(tīng)這個(gè)注冊(cè)中心，發(fā)現(xiàn)有鎖還在被持有，但是Redis 已經(jīng)快過(guò)期了，則修改相應(yīng)key的失效時(shí)間，進(jìn)行續(xù)期。
分布式系統(tǒng)你們是怎么實(shí)現(xiàn)應(yīng)用的？
分布式系統(tǒng)搭建確實(shí)是比較困難的，涉及的點(diǎn)比較多，有幸參與過(guò)，來(lái)說(shuō)說(shuō)自己的拙見(jiàn)吧！
下面以保險(xiǎn)公司為例:
1，應(yīng)用服務(wù):根據(jù)業(yè)務(wù)系統(tǒng)分為契約，核保，批改，理賠，每個(gè)大的系統(tǒng)下面可能會(huì)有細(xì)分！至少要保證四個(gè)大的服務(wù)群！
服務(wù):都是使用spring cloud搭建公司的微服務(wù)，保證各系統(tǒng)之間的服務(wù)對(duì)外提供，每個(gè)服務(wù)對(duì)外提供都使用nginx進(jìn)行負(fù)載均衡，真正的應(yīng)用服務(wù)有四臺(tái)或者兩臺(tái)！
數(shù)據(jù)庫(kù):每個(gè)業(yè)務(wù)對(duì)應(yīng)的服務(wù)系統(tǒng)連接8庫(kù)1024表，使用mycat中間件搭建的分庫(kù)分表，單表保證數(shù)據(jù)不超過(guò)1000萬(wàn)，也就是每個(gè)服務(wù)的數(shù)據(jù)容納能力為102億的數(shù)據(jù)記錄！數(shù)據(jù)都是用邏輯刪除，考慮對(duì)三年期以上的數(shù)據(jù)進(jìn)行數(shù)據(jù)轉(zhuǎn)移保存，在數(shù)據(jù)庫(kù)中進(jìn)行物理刪除！
nosql:使用mongoDB對(duì)大部分key value形式的中間json數(shù)據(jù)進(jìn)行讀取效率，使用redis緩存諸如枚舉，定義表等可靜態(tài)處理的數(shù)據(jù)，使用redis實(shí)現(xiàn)分布式鎖，全局session等實(shí)現(xiàn)單點(diǎn)登錄！
2，消息傳輸:
batch:采用自寫(xiě)的批（i batch）處理框架，根據(jù)不同的調(diào)用異常，數(shù)據(jù)錯(cuò)誤等采取不同的重試機(jī)制，減少人工干預(yù)，多次重試不能通過(guò)的數(shù)據(jù)，發(fā)郵件進(jìn)行人工處理！
消息:同時(shí)使用消息中間件（kafka.ons都用過(guò)）進(jìn)行服務(wù)之間數(shù)據(jù)傳輸，消息先進(jìn)行數(shù)據(jù)落庫(kù)，避免數(shù)據(jù)的丟失，各步驟有返回值判斷加重試機(jī)制，保證各服務(wù)之間數(shù)據(jù)的一致性！
3，數(shù)據(jù)驅(qū)動(dòng):
到此，以上就是小編對(duì)于redis分布式應(yīng)用的方法是什么意思的問(wèn)題就介紹到這了，希望這2點(diǎn)解答對(duì)大家有用。
本文題目：分布式系統(tǒng)你們是怎么實(shí)現(xiàn)應(yīng)用的？
當(dāng)前路徑：http://www.dlmjj.cn/article/cdsjdhp.html
