分佈式鎖概述

大型網站及應用都是分佈式部署的，在分佈式環境中的數據一致性問題一直是一個比較重要的話題，如何保證數據的一致性，那就離不開分佈式鎖。那麼問題也就接踵而至。分佈式鎖有基於數據庫的行數、redis以及zookeeper三種實現方式，一樣是分佈式鎖，三者的區別何在？各自適用什麼場景？
一.場景

• 電商場景中的秒殺、搶購；保證產品不超賣。
• 好比是在分佈式集羣環境裏，多個客戶端同時修改一個共享的數據保證數據的一致性。

二.分佈式鎖的方案

• 基於數據庫的行鎖，有樂觀鎖、悲觀鎖。
• 使用redis來解決，也有樂觀鎖和悲觀鎖兩種實現。
• 基於zookeeper

三.幾種方案的比較

• 基於數據庫的實現，首先數據庫的訪問其實就是對磁盤文件的訪問，高併發環境下，磁盤IO讀寫過多，確定會佔用不少資源，必然致使CPU佔用會居高不下，在高併發的狀況下，確定不能如此高頻率的去讀寫數據庫。並且mysql是一個鏈接給一個線程，當併發高的時候，每秒須要幾百個甚至更多的線程，其中建立和銷燬線程也很耗費性能。
• redis實現，首先redis自己是一個cache，全部的操做都在內存中進行的。固然redis是支持落地的（題外話）。
  
• zk.......等研究好了補上。

四.悲觀鎖和樂觀鎖的選擇
我總結了一下有這麼幾點：

1. 響應時間
2. 衝突頻率
3. 重試代價

若是須要很是高的響應速度，建議使用樂觀鎖,成功就執行，不成功就失敗，不須要等待其餘併發去釋放鎖。若是衝突頻率高或者重試代價大建議使用悲觀鎖。

五.實現方式
數據庫的悲觀鎖和樂觀鎖

• 悲觀鎖使用mybatis的能夠用for update。
• 樂觀鎖直接用版本號

redis悲觀鎖和樂觀鎖

• 悲觀鎖 SETNX
• 樂觀鎖 WATCH MULTI EXEC

zk實現

.................

下一篇將具體介紹如何使用redis實現分佈式鎖，敬請期待！