如何解決redis并發競争key

但上述情況僅适用于單機系統，如果是多個系統并發操作redis，就有可能造成資料丢失、資料覆寫等并發問題；

打個比方，有ABC三個系統

A系統要把變量a指派為1；

B系統要把變量a指派為2；

C系統要把變量a指派為3；

本來我們期望順序執行A > B > C後，a的值為3，但是如果并發太大，導緻A晚了一步，讓BC先執行了，最後a的值就成1了；

解決方案

1、分布式鎖+時間戳

分布式鎖目前的方案主要有三種：

1、基于資料庫；

2、基于redis；

3、基于zooKeeper

分布式鎖具體實作思路請看分布式鎖實作思路，講的很詳細

！！！

注意一點，很多小白不知道，像基于zk或者redis實作的分布式鎖，都有封裝好的工具，zk的是Apache開源的curator，redis的沒用過不知道自己去找，是以其實是不需要我們自己手動實作鎖，這些工具開箱即用，我們能像使用普通lock一樣實作分布式鎖；

在操作a變量時候，額外維護一個時間戳，打個比方

A在執行的時候時間是19:13:30

B在執行的時候時間是19:13:33

C在執行的時候時間是19:13:35

假如B先執行，B執行完後a變量對應的時間戳值應為19:13:33

這時候A再來，發現目前時間是19:13:30，而a對應的時間戳為19:13:33，早于目前時間，說明在自己執行之前已經有其他系統操作過了，這時候就根據實際業務來決定怎麼繼續，廢棄A操作或者輪詢等；

2、基于消息隊列

這種實作方式比較簡單，是目前主流的解決方案

把所有操作寫入同一個隊列，利用消息隊列把所有操作串行化

詳細思路請移步rabbitMQ如何保證消息順序消費和避免消息重複消費