三大引擎分析
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的問題：鎖失效問題和單點問題。
- 沒有提供引擎的降級方案，也不能一鍵切換引擎，需要業務機器停下業務逐個切換。
- 需要提供專屬集羣。
- 代碼層次需要優化，註釋相對較少。
項目的改進
- curator最流行的zookeeper的客戶端，對分佈式鎖有很好的支持，有提供模仿jdk鎖的API，對項目的後期改進空間較大，故zookeeper引擎內部zookeeper客戶端換成curator。
- 增加一個服務端以及web界面，管理分佈式鎖客戶端機器的狀態信息（記錄連接機器的IP地址、持有鎖的機器的IP地址、機器的appkey等），以及集羣的鎖的記錄等信息管理和查看。
- 由於業務在運行時對引擎進行切換，服務端會丟失鎖的記錄信息，而且沒有較好的解決方案；同時大多數業務在給出需求時就可以確定最合適的引擎，故除去引擎降級方案，增加另一集羣進行切換。
- 需要建立容災機制，雙中心容災或異地容災後期研究。
- 目前已知tair引擎在併發量大的時候會出現請求超時問題，需要查看集羣狀態，後期研究改進。
- 提供鑑權，同時對appkey和secret的校驗移至服務端進行。
- 提供統計功能：統計單個機器調用分佈式鎖次數，調用成功和失敗次數，異常統計。
- 解決redlock的問題，同時squirrel的redission的方案進行研究。