Redis併發競爭key的解決方案詳解

Redis高併發的問題

Redis緩存的高性能有目共睹，應用的場景也是很是普遍，可是在高併發的場景下，也會出現問題：

今天要談到的Redis併發競爭問題，這裏的併發指的是多個redis的client同時set key引發的併發問題。

好比：多客戶端同時併發寫一個key，一個key的值是1，原本按順序修改成2,3,4，最後是4，可是因爲併發設置的緣由，最後順序變成了4,3,2，最後變成的key值成了2。

高併發架構系列：Redis併發競爭key的解決方案詳解

如何解決Redis的併發競爭key問題

第一種方案：分佈式鎖

1.總體技術方案

這種狀況，主要是準備一個分佈式鎖，你們去搶鎖，搶到鎖就作set操做。

2.爲何是分佈式鎖

由於傳統的加鎖的作法（如java的synchronized和Lock）這裏沒用，只適合單點。由於這是分佈式環境，須要的是分佈式鎖。

固然，分佈式鎖能夠基於不少種方式實現，好比zookeeper、redis等，無論哪一種方式實現，基本原理是不變的：用一個狀態值表示鎖，對鎖的佔用和釋放經過狀態值來標識。

3.分佈式鎖的要求

• 互斥性：在任意一個時刻，只有一個客戶端持有鎖。
• 無死鎖：即使持有鎖的客戶端崩潰或者其餘意外事件，鎖仍然能夠被獲取。
• 容錯：只要大部分Redis節點都活着，客戶端就能夠獲取和釋放鎖

4.分佈式鎖的實現方式

• 數據庫
• Memcached（add命令）
• Redis（setnx命令）
• Zookeeper（臨時節點）

具體的分佈式鎖實現，請參考：阿里P8架構師談：分佈式鎖的3種實現（數據庫、緩存、Zookeeper)

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

在併發量過大的狀況下,能夠經過消息中間件進行處理,把並行讀寫進行串行化。

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

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