模擬搶券場景

通過下面方法添加Synchronized鎖來防止上述情況，

如果上面是單體服務(wù)沒有問題，但是如果項目是集群部署，會出現(xiàn)下面的問題，因為Synchronized是屬于本地的鎖

端口8080和8081同時訪問，那么兩個線程會同時加鎖

這時候我們需要用分布式鎖

8080端口在進行線程1的時候，進行加鎖，此時8081的進行訪問的時候獲取互斥鎖失敗，可以保證數(shù)據(jù)一致

Redis 分布式鎖實現(xiàn)原理

為什么要設(shè)置過期時間？如果不設(shè)置過期時間的話，有可能導(dǎo)致死鎖的問題。

Redis實現(xiàn)分布式鎖如何合理的控制鎖的有效時長？

1.根據(jù)業(yè)務(wù)執(zhí)行時間預(yù)估，2.給鎖續(xù)期，但是第一種根據(jù)業(yè)務(wù)執(zhí)行的時間預(yù)估依然可能會出現(xiàn)問題，所以我們采用第二種方案給鎖續(xù)期，但是我們要自己再開一個線程一直關(guān)注這個鎖嗎？Redis 分布式鎖就可以實現(xiàn)

下面這個線程加鎖成功的話，跟上面的流程是一樣的，如果加鎖不成功，就會循環(huán)，不斷嘗試獲取鎖，但是也不會一直循環(huán)，有設(shè)置閾值，循環(huán)次數(shù)達到閾值就會停止
具體代碼：

加鎖，設(shè)置過期時間等操作都是基于lua腳本完成

add1 方法加鎖 ，Value.value = 1, 之后調(diào)用add2 方法加鎖，Value.value = 2, add2 釋放鎖 Value.value-1變成1 ，之后add1 釋放鎖 Value.value-1變成0

只有同一個線程才會重入

主從一致性

假如現(xiàn)在在寫入數(shù)據(jù)到主節(jié)點，這時候主節(jié)點宕機了，會有一個從節(jié)點變成主節(jié)點，當有請求來了，繼續(xù)寫入數(shù)據(jù)，也會嘗試獲取鎖，因為之前的數(shù)據(jù)沒同步過來，這時候就會造成兩個線程同時持有同一把鎖，但是這樣就沒有互斥性了，業(yè)務(wù)還在執(zhí)行就可能會產(chǎn)生臟數(shù)據(jù)，因此在Redis中還提供了另外一種鎖——紅鎖

紅鎖

其中 n 代表redis中節(jié)點的數(shù)量，創(chuàng)建鎖的個數(shù)要大于等于節(jié)點的一半才行，來解決主從不一致的問題，但是這種方法實現(xiàn)復(fù)雜，性能查并且運維繁瑣。
Redis 的思想是AP思想，保證數(shù)據(jù)最終一致，但是如果必須保證完全實時一致，就需要用CP思想，用zookeeper