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