這篇文章將為大家詳細(xì)講解有關(guān)如何使用Redis實(shí)現(xiàn)分布式鎖，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

創(chuàng)新互聯(lián)建站是一家專注于網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作與策劃設(shè)計(jì),武昌網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)建站做網(wǎng)站,專注于網(wǎng)站建設(shè)10年,網(wǎng)設(shè)計(jì)領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:武昌等地區(qū)。武昌做網(wǎng)站價(jià)格咨詢:13518219792

加鎖部分

解鎖部分

主要原理是使用了 redis 的 setnx 去插入一組 key-value，其中 key 要上鎖的標(biāo)識(shí)（在項(xiàng)目中是鎖死用戶 userId），如果上鎖失敗則返回 false。但是根據(jù)二段鎖的思路，仔細(xì)思考會(huì)存在這么一個(gè)有趣的現(xiàn)象：

假設(shè)微服務(wù) A 的某個(gè)請(qǐng)求對(duì) userId = 7 的用戶上鎖，則微服務(wù) A 的這個(gè)請(qǐng)求可以讀取這個(gè)用戶的信息，且可以修改其內(nèi)容 ；其他模塊只能讀取這個(gè)用戶的信息，無(wú)法修改其內(nèi)容。
假設(shè)微服務(wù) A 的當(dāng)前請(qǐng)求對(duì) userId = 7 的用戶解鎖，則所有模塊可以讀取這個(gè)用戶的信息，且可以修改其內(nèi)容
如此一來(lái)：

• 若微服務(wù)模塊 A 接收到另一個(gè)需要修改 userId = 7 的用戶 的請(qǐng)求時(shí)，假設(shè)這個(gè)用戶還在被鎖狀態(tài)下，這次請(qǐng)求可以修改它嗎？（可以，解個(gè)鎖就行）

• 若微服務(wù)模塊 B 接收到另一個(gè)需要修改 userId = 7 的用戶 的請(qǐng)求時(shí)，假設(shè)這個(gè)用戶還在被鎖狀態(tài)下，這次請(qǐng)求可以修改它嗎？（可以，解個(gè)鎖就行）

• 若微服務(wù)模塊 A 執(zhí)行上鎖的請(qǐng)求中途意外崩掉，其他用戶還能修改信息嗎？ （可以，解個(gè)鎖就行）

很明顯，這三點(diǎn)并不是我們所希望的。那么如何實(shí)現(xiàn)分布式鎖才是最佳實(shí)踐吶？

一個(gè)好的分布式鎖需要實(shí)現(xiàn)什么

• 由某個(gè)模塊的某次請(qǐng)求上鎖，并且只有由這個(gè)模塊的這次請(qǐng)求解鎖（互斥，只能有一個(gè)微服務(wù)的某次請(qǐng)求持有鎖）

• 若上鎖模塊的上鎖請(qǐng)求超時(shí)執(zhí)行，則應(yīng)自動(dòng)解鎖，并還原其所做修改（容錯(cuò)，就算 一個(gè)持有鎖的微服務(wù)宕機(jī)也不影響最終其他模塊的上鎖 ）

我們應(yīng)該怎么做

綜上所述，我們小組的分布式鎖在實(shí)現(xiàn)模塊互斥的情況下，忽略的一個(gè)重要問(wèn)題便是“請(qǐng)求互斥”。我們只需要在加鎖時(shí)，key-value 的值保存為當(dāng)前請(qǐng)求的 requestId ，解鎖時(shí)加多一次判斷，是否為同一請(qǐng)求即可。

那么這么修改之后，我們可以高枕無(wú)憂了嗎?

是的，夠用了。因?yàn)槲覀冮_發(fā)環(huán)境 Redis 是統(tǒng)一用一臺(tái)服務(wù)器上的單例，采用上述方式實(shí)現(xiàn)的分布式鎖并沒有什么問(wèn)題，但在準(zhǔn)備部署到生產(chǎn)環(huán)境下時(shí)，突然意識(shí)到一個(gè)問(wèn)題：如果實(shí)現(xiàn)主從讀寫分離，redis 多機(jī)主從同步數(shù)據(jù)時(shí)，采用的是異步復(fù)制，也便是一個(gè)“寫”操作到我們的 reids 主庫(kù)之后，便馬上返回成功（并不會(huì)等到同步到從庫(kù)后再返回，如果這種是同步完成后再返回便是同步復(fù)制），這將會(huì)造成一個(gè)問(wèn)題：

假設(shè)我們的模塊 A中 id=1 的請(qǐng)求上鎖成功后，沒同步到從庫(kù)前主庫(kù)被我們玩壞了（宕機(jī)），則 redis 哨兵將會(huì)從從庫(kù)中選擇出一臺(tái)新的主庫(kù)，此時(shí)若模塊 A 中 id=2 的請(qǐng)求重新請(qǐng)求加鎖，將會(huì)是成功的。

技不如人，我們只能借助搜索引擎劃水了（大霧），發(fā)現(xiàn)這種情況還真的有通用的解決方案：redlock。

怎么實(shí)現(xiàn) Redlock 分布式安全鎖

首先 redlock 是 redis 官方文檔推薦的實(shí)現(xiàn)方式，本身并沒有用到主從層面的架構(gòu)，采用的是多態(tài)主庫(kù)，依次去取鎖的方式。假設(shè)這里有 5 臺(tái)主庫(kù)，整體流程大致如下：

加鎖

1. 應(yīng)用層請(qǐng)求加鎖

2. 依次向 5 臺(tái) redis 服務(wù)器發(fā)送請(qǐng)求

3. 若有超過(guò)半數(shù)的服務(wù)器返回加鎖成功，則完成加鎖，如果沒有則自動(dòng)執(zhí)行解鎖，并等待一段隨機(jī)時(shí)間后重試。（客觀原因加鎖失敗：網(wǎng)絡(luò)情況不好、服務(wù)器未響應(yīng)等問(wèn)題， 等待一段隨機(jī)時(shí)間后重試可以避開“蜂擁而進(jìn)”的情況造成服務(wù)器資源占用瞬時(shí)猛增 ）

4. 如有其中任意一臺(tái)服務(wù)器已經(jīng)持有該鎖，則加鎖失敗， 等待一段隨機(jī)時(shí)間后重試。 （主觀原因加鎖失敗：已經(jīng)被被別人鎖上了）

解鎖

直接向 5 臺(tái)服務(wù)器發(fā)起請(qǐng)求即可，無(wú)論這臺(tái)服務(wù)器上是不是已經(jīng)有鎖。

整體思路很簡(jiǎn)單，但是實(shí)現(xiàn)起來(lái)仍有許多值得注意的地方。在向這 5 臺(tái)服務(wù)器發(fā)送加鎖請(qǐng)求時(shí)，由于會(huì)帶上一個(gè)過(guò)期時(shí)間以保證上文所提到的“自動(dòng)解鎖(容錯(cuò)性) ”，考慮到延時(shí)等原因，這 5 臺(tái)機(jī)自動(dòng)解鎖的時(shí)間不完全相同，因此存在一個(gè)加

鎖時(shí)間差的問(wèn)題，一般而言是這么解決的：

• 在加鎖之前，必須在應(yīng)用層（或者把分布式鎖單獨(dú)封裝成一個(gè)全局通用的微服務(wù)亦可）2. 記錄請(qǐng)求加鎖的時(shí)間戳 T1

• 完成最后一臺(tái) redis 主庫(kù)加鎖后，記錄時(shí)間戳 T2

• 則加鎖所需時(shí)間為 T1 – T2

• 假設(shè)資源自動(dòng)解鎖的時(shí)間為 10 秒后，則資源真正可利用的時(shí)間為 10 – T1 + T2。若

可利用時(shí)間不符合預(yù)期，或者為負(fù)數(shù)，你懂的，重新來(lái)一遍吧。

如果你對(duì)鎖的過(guò)期時(shí)間有著更加嚴(yán)格的把控，可以把 T1 到第一臺(tái)服務(wù)器加鎖成功的時(shí)間單獨(dú)記錄，再在最后的可用時(shí)間上加上這段時(shí)間即可得到一個(gè)更加準(zhǔn)確的值

現(xiàn)在考慮另一個(gè)問(wèn)題，如果恰好某次請(qǐng)求的鎖保存在了三臺(tái)服務(wù)器上，其中這三臺(tái)都宕機(jī)了（怎么這么倒霉.. TAT），那此時(shí)另一個(gè)請(qǐng)求又來(lái)請(qǐng)求加鎖，豈不又回到最初我們小組所面臨的問(wèn)題了？很遺憾的說(shuō)，是的，在這種問(wèn)題上官方文檔給出的答案是：?jiǎn)⒂肁OF持久化功能情況會(huì)得到好轉(zhuǎn) ?

關(guān)于性能方面的處理， 一般而言不止要求低延時(shí)，同時(shí)要求高吞吐量，我們可以按照官方文檔的說(shuō)法， 采用多路傳輸同時(shí)對(duì) 5 臺(tái) redis 主庫(kù)進(jìn)行通信以降低整體耗時(shí)，或者把 socket 設(shè)置成非阻塞模式 （這樣的好處是發(fā)送命令時(shí)并不等待返回，因此可以一次性發(fā)送全部命令再進(jìn)行等待整體運(yùn)行結(jié)果，雖然本人認(rèn)為通常情況下如果本身網(wǎng)絡(luò)延遲極低的情況下作用不大，等待服務(wù)器處理的時(shí)間占比會(huì)更加大）

關(guān)于如何使用Redis實(shí)現(xiàn)分布式鎖就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

本文標(biāo)題：如何使用Redis實(shí)現(xiàn)分布式鎖-創(chuàng)新互聯(lián)
網(wǎng)站URL：http://www.js-pz168.com/article38/jjcsp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供關(guān)鍵詞優(yōu)化、手機(jī)網(wǎng)站建設(shè)、外貿(mào)建站、靜態(tài)網(wǎng)站、網(wǎng)頁(yè)設(shè)計(jì)公司、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)