zookeeper 分布式鎖

分布式鎖肯定是用在分布式環境下。在分布式環境下，使用分布式鎖的目的也是保證同一時刻只有乙個執行緒來修改共享變數，修改共享快取……。

前景：jdk提供的鎖只能保證執行緒間的安全性，但分布式環境下，各節點之間的執行緒同步執行卻得不到保障，分布式鎖由此誕生。

實現方式有以下幾種：

基於資料庫實現分布式鎖；

基於快取（redis等）實現分布式鎖；

基於zookeeper實現分布式鎖；

生成訂單號會出現多執行緒安全問題：

在分布式情況，生成全域性訂單號id

使用時間戳

使用uuid

推特 (twitter) 的 snowflake 演算法——用於生成唯一 id

//使用多執行緒模擬生成訂單號
public class orderservice implements runnable 
public void getnumber() 
public static void main(string args) 
}}

使用synchronized或者loca鎖

//使用多執行緒模擬生成訂單號
public class orderservice implements runnable 
public void getnumber() 
} public static void main(string args) 
}}

public class orderservice implements runnable 
public void getnumber() 
} catch (exception e) finally 
} public static void main(string args) 
}}

生成的唯一id需要具備哪些條件

全域性唯一性：不能出現重複的id號，既然是唯一標識，這是最基本的要求。

趨勢遞增：在mysql innodb引擎中使用的是聚集索引，由於多數rdbms使用b-tree的資料結構來儲存索引資料，在主鍵的選擇上面我們應該盡量使用有序的主鍵保證寫入效能。

uuid

關於分布式id,很多人會想到使用uuid，uuid在唯一性上確實可以達到這個目的，但它也存在很大的缺陷

優點：缺點：

在分布式情況，生成全域性訂單號id

在分布式(集群)環境下，每台jvm不能實現同步，在分布式場景下使用時間戳生成訂單號可能會重複

使用分布式鎖

提前生成好，訂單號，存放在redis取。獲取訂單號，直接從redis中取。

1.使用資料庫實現分布式鎖

缺點:效能差、執行緒出現異常時，容易出現死鎖

2.使用redis實現分布式鎖

缺點:鎖的失效時間難控制、容易產生死鎖、非阻塞式、不可重入

3.使用zookeeper實現分布式鎖

實現相對簡單、可靠性強、使用臨時節點，失效時間容易控制

分布式鎖一般用在分布式系統或者多個應用中，用來控制同一任務是否執行或者任務的執行順序。在專案中，部署了多個tomcat應用，在執行定時任務時就會遇到同一任務可能執行多次的情況，我們可以借助分布式鎖，保證在同一時間只有乙個tomcat應用執行了定時任務

使用zookeeper建立臨時序列節點來實現分布式鎖，適用於順序執行的程式，大體思路就是建立臨時序列節點，找出最小的序列節點，獲取分布式鎖，程式執行完成之後此序列節點消失，通過watch來監控節點的變化，從剩下的節點的找到最小的序列節點，獲取分布式鎖，執行相應處理，依次類推……

com.101tec zkclient 0.10

**不貼了，有點