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並發競爭的解決方案。
第一種方案：分布式鎖+時間戳
1.整體技術方案
這種情況，主要是准備一個分布式鎖，大家去搶鎖，搶到鎖就做set操作。
加鎖的目的實際上就是把並行讀寫改成串行讀寫的方式，從而來避免資源競爭。
2.Redis分布式鎖的實現
主要用到的redis函數是setnx()
用SETNX實現分布式鎖
利用SETNX非常簡單地實現分布式鎖。例如：某客戶端要獲得一個名字youzhi的鎖，客戶端使用下面的命令進行獲取：
SETNX lock.youzhi<current Unix time + lock timeout + 1>
- 如返回1，則該客戶端獲得鎖，把lock.youzhi的鍵值設置為時間值表示該鍵已被鎖定，該客戶端最后可以通過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等，不管哪種方式實現，基本原理是不變的：用一個狀態值表示鎖，對鎖的占用和釋放通過狀態值來標識。
第二種方案：利用消息隊列
在並發量過大的情況下,可以通過消息中間件進行處理,把並行讀寫進行串行化。
把Redis.set操作放在隊列中使其串行化,必須的一個一個執行。
這種方式在一些高並發的場景中算是一種通用的解決方案。
以上來自https://zhuanlan.zhihu.com/p/52756935
第三種：使用synchronized靜態方法，原理類似消息隊列。