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操作放在隊列中使其串行化,必須的一個一個執行。
這種方式在一些高并發的場景中算是一種通用的解決方案。
本文由部落格一文多發平台 OpenWrite 釋出！