Redis分布式鎖的原理是什么？如何續(xù)期？分布式鎖的需求伴隨著應(yīng)用的分布式部署。在單個(gè)應(yīng)用程序只部署一臺(tái)服務(wù)器的情況下，可以通過Java同步鎖來實(shí)現(xiàn)。同步鎖是一種原子操作。當(dāng)應(yīng)用程序以分布式方式部署并

Redis分布式鎖的原理是什么？如何續(xù)期？

分布式鎖的需求伴隨著應(yīng)用的分布式部署。在單個(gè)應(yīng)用程序只部署一臺(tái)服務(wù)器的情況下，可以通過Java同步鎖來實(shí)現(xiàn)。同步鎖是一種原子操作。

當(dāng)應(yīng)用程序以分布式方式部署并且具有多個(gè)服務(wù)時(shí)，應(yīng)用服務(wù)器將無法提供原子操作。Redis具有高性能，而且是單線程的，因此它可以為原子操作提供一個(gè)場(chǎng)所。有了它，就可以實(shí)現(xiàn)分布式鎖。

怎么實(shí)現(xiàn)redis的讀鎖？

避免落入setnx（set if not exists）陷阱的最好方法是永遠(yuǎn)不要使用它：

setnx lock“l(fā)ock”

expire lock 100

del lock

場(chǎng)景：查詢數(shù)據(jù)庫的接口有大量調(diào)用，因此添加了緩存，問題是當(dāng)并發(fā)量大的時(shí)候，如果沒有鎖機(jī)制，大量的并發(fā)請(qǐng)求會(huì)在緩存過期的時(shí)候穿透緩存，直接查詢數(shù)據(jù)庫，造成雪崩效應(yīng)，如果有鎖機(jī)制，只能處理一個(gè)請(qǐng)求控制以更新緩存。其他請(qǐng)求根據(jù)情況等待或使用過期的緩存。

$key=“cache update Lock”//Lock

$random=MD5（uniqid（getmypid（））。“”.mturand（）.“”，true））//隨機(jī)值

$TTL=10//NX不存在，ex為過期時(shí)間，TTL為生存時(shí)間，單位為秒

如果（$redis->set（$key，$random，[“NX”，“ex”=>$TTL]）{

$cache->update（）//鎖定后，執(zhí)行業(yè)務(wù)邏輯，這里是update cache

//添加隨機(jī)值判斷以避免刪除其他操作的鎖

如果（$redis->get（$key）==$random）{

$redis->del（$key）}

什么時(shí)候需要分布式鎖？

首先，您需要知道在非分布式環(huán)境中使用鎖可以解決什么問題？

多線程環(huán)境，共享資源線程安全問題！此時(shí)，共享資源通常在一臺(tái)機(jī)器的多線程中競(jìng)爭(zhēng)。從JAVA內(nèi)存模型的角度來看，我們可以通過鎖定對(duì)象、方法和代碼塊來避免共享資源的競(jìng)爭(zhēng)

！1，生成全局ID；

2，修改全局配置文件；

3，分布式服務(wù)中的seckill；

4，分布式環(huán)境中的重復(fù)提交；

1，使用數(shù)據(jù)庫的唯一主鍵實(shí)現(xiàn)鎖定

！2、使用redis指令：通常使用setnx方法，incr方法實(shí)現(xiàn)

3、使用zookeeper：使用API生成臨時(shí)節(jié)點(diǎn)實(shí)現(xiàn)鎖定

分布式鎖用zookeeper還是redis好？

1. 無法重新進(jìn)入

2。沒有本地鎖，并發(fā)性能會(huì)很差。它不用于并發(fā)鎖爭(zhēng)用較多的場(chǎng)景。本地鎖沒有自旋

3。不考慮鎖等待排序。redis很難實(shí)現(xiàn)，可以通過redis的列表實(shí)現(xiàn)，但是列表下的每個(gè)子節(jié)點(diǎn)都沒有超時(shí)。Redis也不能執(zhí)行模糊查詢key*

所以最好通過zookeeper實(shí)現(xiàn)當(dāng)我們遇到性能瓶頸時(shí)，我們的離線查詢常常無法注冊(cè)。Redis沒有鎖機(jī)制。多用戶連接沒有競(jìng)爭(zhēng)。但在并發(fā)過程中，可能會(huì)出現(xiàn)連接超時(shí)、連接阻塞或連接關(guān)閉等錯(cuò)誤。一般來說，連接可以在客戶端進(jìn)行池化（例如讀寫redis時(shí)使用synchronized來添加內(nèi)部鎖），也可以在服務(wù)器端使用redis的事務(wù)處理命令setnx來實(shí)現(xiàn)鎖。