分散式鎖框架分析
阿新 • • 發佈：2018-12-06
三大引擎分析
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的方案進行研究。