分佈式鎖框架分析

三大引擎分析

zookeeper引擎分析

優勢：

• 鎖安全性高，zk可持久化，且能實時監聽獲取鎖的客戶端狀態。
• zookeeper支持watcher機制，這樣實現阻塞鎖，能夠watch鎖數據，等到數據被刪除，zookeeper會通知客戶端去從新競爭鎖。
• zookeeper的數據能夠支持臨時節點的概念，即客戶端寫入的數據是臨時數據，在客戶端宕機後，臨時數據會被刪除，這樣就實現了鎖的異常釋放。使用這樣的方式，就不須要給鎖增長超時自動釋放的特性了。

缺點：

• 性能開銷比較高。由於其須要動態產生、銷燬瞬時節點來實現鎖功能。因此不太適合直接提供給高併發的場景使用。
• zk使用的Zab的一致性協議，寫是一個兩階段協議，效率上要差一些。
• 使用watch時，因爲watch使用較多，watch對zookeeper性能有必定影響。

適用場景：

• 對可靠性要求很是高，且併發程度不高的場景下使用。如核心數據的定時全量/增量同步等。


tair引擎分析

優勢：

• 同時支持分佈式緩存和持久化存儲。
• 自動的複製和遷移，自動擴容。
• tair支持Version、原子計數、和Item支持。
• 使用的中心化的架構設計和一致性 hash 算法的數據分佈，同時支持在線數據遷移。
• 數據可靠性⾼、成本低。

缺點：

• 在⼤併發訪問下性能可能會有較⼤抖動
• 在某些狀況下（如客戶端gc、磁盤io、慢請求阻塞）會致使請求超時問題，在分佈式鎖的使用中會致使獲取鎖失敗。

場景：

• 數據規模較⼤、冷熱數據顯著的業務場景，對分佈式鎖可靠性有必定要求，但併發量要求沒有過高的時候使用。

redis引擎分析

優勢：

• 併發高效，redis自3.0自身支持集羣，同時支持哨兵機制，高性能低延遲。
• redis能夠持久化數據。
• redis使用單進程單線程，內存存儲，速度很是快，比memcached還要快不少，因此支持的併發訪問量能夠很高。
• 現已有成熟的java客戶端，如jedis。

缺點：

• redis採用某些淘汰策略，因此若是內存不夠，可能致使緩存中的鎖信息丟失。
• 一旦緩存服務宕機，鎖數據就丟失了。像redis自帶複製功能，能夠對數據可靠性有必定的保證，可是因爲複製也是異步完成的，所以依然可能出現master節點寫入鎖數據而未同步到slave節點的時候宕機，鎖數據丟失問題。
• 須要加入超時機制避免死鎖。
• 成本較高。

場景：

• 高併發，須要加入超時機制避免死鎖，提供足夠的支撐鎖服務的內存空間，穩定的集羣化管理，同時沒有對數據的可靠性有較高要求。

自研分佈式鎖分析

優勢：

• 提供了引擎的多種選擇，多種可靠性和不一樣併發量的階梯選擇。
• 可擴展性強，能夠加入其餘引擎。
• zk引擎和tair引擎目前都支持可重入讀寫鎖。
• 做爲一個sdk，可使用jar包直接導入，業務使用簡單。

缺點：

• 目前相對而言，相對粗糙，多種功能未完成，已有功能需完善。
• 目前沒有管理界面和工具，排錯須要到集羣上和業務機器上進行。
• 沒有創建容災機制。
• tair請求超時問題未解決。
• tair的可重入讀寫鎖暫時支持的不夠好，須要研究改進。
• redis存在redlock的問題：鎖失效問題和單點問題。
• 沒有提供引擎的降級方案，也不能一鍵切換引擎，須要業務機器停下業務逐個切換。
• 須要提供專屬集羣。
• 代碼層次須要優化，註釋相對較少。

項目的改進

1. curator最流行的zookeeper的客戶端，對分佈式鎖有很好的支持，有提供模仿jdk鎖的API，對項目的後期改進空間較大，故zookeeper引擎內部zookeeper客戶端換成curator。
2. 增長一個服務端以及web界面，管理分佈式鎖客戶端機器的狀態信息（記錄鏈接機器的IP地址、持有鎖的機器的IP地址、機器的appkey等），以及集羣的鎖的記錄等信息管理和查看。
3. 因爲業務在運行時對引擎進行切換，服務端會丟失鎖的記錄信息，並且沒有較好的解決方案；同時大多數業務在給出需求時就能夠肯定最合適的引擎，故除去引擎降級方案，增長另外一集羣進行切換。
4. 須要創建容災機制，雙中心容災或異地容災後期研究。
5. 目前已知tair引擎在併發量大的時候會出現請求超時問題，須要查看集羣狀態，後期研究改進。
6. 提供鑑權，同時對appkey和secret的校驗移至服務端進行。
7. 提供統計功能：統計單個機器調用分佈式鎖次數，調用成功和失敗次數，異常統計。
8. 解決redlock的問題，同時squirrel的redission的方案進行研究。