本篇就接著來談Redis在高并發的場景，如何來解決并發競爭Key的解決方案。

01

—

并發競爭的由來

1.Redis高并發的問題

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

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

2.出現并發設置Key的原因

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

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

3.舉一個例子

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

?

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

02

—

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

1.整體技術方案

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

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

2.Redis分布式鎖的實現

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

用SETNX實現分布式鎖

利用SETNX非常簡單地實現分布式鎖。例如：某客戶端要獲得一個名字mikechen的鎖，客戶端使用下面的命令進行獲取：

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

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

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

  
  

2.時間戳

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

系統A key 1 {ValueA 7:00}

系統B key 1 { ValueB 7:05}

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

3.什么是分布式鎖

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

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

關于分布式鎖可以查看：分布式鎖的實現原理與應用場景詳解

03

—

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

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

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

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

閱讀原文：原文鏈接