需求由來

1.Redis高并發(fā)的問題

Redis緩存的高性能有目共睹，應(yīng)用的場景也是非常廣泛，但是在高并發(fā)的場景下，也會出現(xiàn)問題：緩存擊穿、緩存雪崩、緩存和數(shù)據(jù)一致性，以及今天要談到的緩存并發(fā)競爭。

這里的并發(fā)指的是多個redis的client同時set key引起的并發(fā)問題。

2.出現(xiàn)并發(fā)設(shè)置Key的原因

Redis是一種單線程機制的nosql數(shù)據(jù)庫，基于key-value，數(shù)據(jù)可持久化落盤。由于單線程所以Redis本身并沒有鎖的概念，多個客戶端連接并不存在競爭關(guān)系，但是利用jedis等客戶端對Redis進行并發(fā)訪問時會出現(xiàn)問題。

比如：同時有多個子系統(tǒng)去set一個key。這個時候要注意什么呢？

3.舉一個例子

多客戶端同時并發(fā)寫一個key，一個key的值是1，本來按順序修改為2,3,4，最后是4，但是順序變成了4,3,2，最后變成了2。

如何解決redis的并發(fā)競爭key問題呢？下面給到2個Redis并發(fā)競爭的解決方案。

第一種方案：分布式鎖+時間戳

1.整體技術(shù)方案

這種情況，主要是準(zhǔn)備一個分布式鎖，大家去搶鎖，搶到鎖就做set操作。

加鎖的目的實際上就是把并行讀寫改成串行讀寫的方式，從而來避免資源競爭。

2.Redis分布式鎖的實現(xiàn)

主要用到的redis函數(shù)是setnx()

用SETNX實現(xiàn)分布式鎖

利用SETNX非常簡單地實現(xiàn)分布式鎖。例如：某客戶端要獲得一個名字youzhi的鎖，客戶端使用下面的命令進行獲?。?/p>

SETNX lock.youzhi<current Unix time + lock timeout + 1>

如返回1，則該客戶端獲得鎖，把lock.youzhi的鍵值設(shè)置為時間值表示該鍵已被鎖定，該客戶端最后可以通過DEL lock.foo來釋放該鎖。

如返回0，表明該鎖已被其他客戶端取得，這時我們可以先返回或進行重試等對方完成或等待鎖超時。

3.時間戳

由于上面舉的例子，要求key的操作需要順序執(zhí)行，所以需要保存一個時間戳判斷set順序。

系統(tǒng)A key 1 {ValueA 7:00}

系統(tǒng)B key 1 { ValueB 7:05}

假設(shè)系統(tǒng)B先搶到鎖，將key1設(shè)置為{ValueB 7:05}。接下來系統(tǒng)A搶到鎖，發(fā)現(xiàn)自己的key1的時間戳早于緩存中的時間戳（7:00<7:05），那就不做set操作了。

4.什么是分布式鎖

因為傳統(tǒng)的加鎖的做法（如java的synchronized和Lock）這里沒用，只適合單點。因為這是分布式環(huán)境，需要的是分布式鎖。

當(dāng)然，分布式鎖可以基于很多種方式實現(xiàn)，比如zookeeper、redis等，不管哪種方式實現(xiàn)，基本原理是不變的：用一個狀態(tài)值表示鎖，對鎖的占用和釋放通過狀態(tài)值來標(biāo)識。

第二種方案：利用消息隊列

在并發(fā)量過大的情況下,可以通過消息中間件進行處理,把并行讀寫進行串行化。

把Redis.set操作放在隊列中使其串行化,必須的一個一個執(zhí)行。

這種方式在一些高并發(fā)的場景中算是一種通用的解決方案。

以上就是Redis并發(fā)競爭key技術(shù)方案詳解，相關(guān)Redis高并發(fā)問題具體還可以參考我的往期分享：高并發(fā)架構(gòu)系列：如何解決Redis雪崩、穿透、并發(fā)等5大難題

我是mike,每日分享bat架構(gòu)+面試+技術(shù)干貨！覺得不錯請點贊支持，歡迎留言或進我的個人群179961551領(lǐng)取【架構(gòu)資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本群專用于學(xué)習(xí)交流技術(shù)、分享面試機會，拒絕廣告，我也會在群內(nèi)不定期答題、探討。