乙個可靠的分布式鎖應該具備以下特性：
互斥性：作為鎖，需要保證任何時刻只能有乙個客戶端(使用者)持有鎖
可重入： 同乙個客戶端在獲得鎖後，可以再次進行加鎖
高可用：獲取鎖和釋放鎖的效率較高，不會出現單點故障
自動重試機制：當客戶端加鎖失敗時，能夠提供一種機制讓客戶端自動重試
加了synchronized是否就解決了以上分布式鎖的問題呢？其實不然，我們知道，在大部分網際網路公司，
乙個web應用都是被打成war包，部署在多個tomcat上面，如果乙個程式在乙個tomcat上面執行，
那麼使用synchronized就沒有問題，但是如果是乙個web應用都是被打成war包，部署在多個tomcat上面，
做成乙個集群架構，以上方法就不適用了。雖然synchronized可以解決數目不一致的問題，但是缺點也很明顯，
那就是慢，因為synchronized修飾的方法是同步的，也就是說每次只有乙個執行緒訪問這個方法，
而且synchronized只適用於單點的情況。
可以用以下命令實現簡單的分布式鎖
入門級別分布式鎖
分布式鎖優化1
分布式鎖優化2
分布式鎖優化3
分布式鎖優化4
概述：在一些高併發的場景中，比如秒殺，搶票，搶購這些場景，都存在對核心資源，商品庫存的爭奪，控制不好，庫存數量可能被減少到負數，出現超賣的情況，或者產生唯一的乙個遞增id，由於web應用部署在多個機器上，簡單的同步加鎖是無法實現的，給資料庫加鎖的話，對於高併發，1000/s的併發，資料庫可能由行鎖變成表鎖，效能下降會厲害。那相對而言，redis的分布式鎖，相對而言，是個很好的選擇，redis官方推薦使用的redisson就提供了分布式鎖和相關服務。下面介紹下如何使用redisson。
redisson的使用方式十分簡單，詳見官方文件：
加入jar包的依賴：
org.springframework.boot<
/groupid>
spring-boot-starter-data-redis<
/artifactid>
<
/dependency>
org.redisson<
/groupid>
redisson<
/artifactid>
3.8.2
<
/version>
true
<
/optional>
<
/dependency>
public
class
redissonmanager
//獲取redisson物件的方法
public
static redisson getredisson()
}
為啥要用lua指令碼呢？
因為一大坨複雜的業務邏輯，可以通過封裝在lua指令碼中傳送給redis，保證這段複雜業務邏輯執行的原子性。
Redis分布式鎖詳解
在網際網路分布式服務部署中，通常會遇到多個程序操作同乙個資源的情況，例如秒殺等，此文章主要介紹使用redis實現分布式鎖。redis為單程序單執行緒模式，採用佇列模式將併發訪問變為序列訪問。通常使用setnx 即set not exiest 來實現鎖，以下通過循序漸進的方式引入最終實現。方案一1.c...
微服務 Redis高併發下分布式鎖實現
傳統的軟體公司，依然堅持用著三層架構，單體的應用程式可以使用synchronized解決高併發下秒殺功能，這樣程式在併發下訪問效率下降，若用nginx反向 啟用分布式應用，synchronized則實現不了分布式鎖，如何解決？利用redis中的setnx可實現高併發下分布式鎖。具體要點和細節記錄在 ...
redis實現分布式鎖詳解
解決問題 應對高併發業務場景 為什麼可以實現？首先redis是單執行緒的，這裡的單執行緒指的是網路請求模組使用了乙個執行緒 所以不需考慮併發安全性 即乙個執行緒處理所有網路請求，其他模組仍用了多個執行緒。實現原理 伺服器一的請求會先獲取到鎖，接下來如果來相同的請求，此時會返回獲取鎖失敗的狀態。直至本...