在分散式系統中，為了保證資料的一致性，往往需要進行同步控制，比如減庫存、唯一流水號生成等。Curator對Zookeeper進行了封裝，實現了分散式鎖的功能，提供了執行緒的同步控制。同時，Curator也提供了多種鎖機制。下面對通過時間戳生成流水號的場景進行逐步分析。

普通示例

先看一個簡單的程式：

package com.secbro.learn.curator;

import java.text.SimpleDateFormat;
import java.util.Date;

/**
 * Created by zhuzs on 2017/5/4.
 */
public class
 
 CreateOrderNo {
    public static void main(String[] args) {
        for(int i=0; i< 10; i++){
            SimpleDateFormat sdf = new SimpleDateFormat("yyyyDDmm HH:mm:ss|SSS");
            String orderNo = sdf.format(new Date());
            System.out.println(orderNo);
        }

    }
}

以上程式碼通過一個迴圈連續打印出10個時間戳。這裡沒有使用多執行緒，但分析下面的列印結果就會發現，其實在同一時刻會生成多個相同的流水號，執行時間在毫秒級別。

201712457 18:57:29|262
201712457 18:57:29|263
201712457 18:57:29|263
201712457 18:57:29|263
201712457 18:57:29|263
201712457 18:57:29|263
201712457 18:57:29|263
201712457 18:57:29|263
201712457 18:57:29|263
201712457 18:57:29|264

如果業務量不大，沒有併發情況，上面生成的流水號重複的可能性不大，一旦出現高併發，那麼重複的訂單號就會大量出現，當然也有其他方案進行解決，本篇文章就不再進行討論。下說說如何通過分散式鎖來解決此問題。

分散式鎖示例

下面的程式碼利用Curator的分散式鎖來實現在同一時刻只會生成一個唯一的流水號。

package com.secbro.learn.curator;

import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.retry.ExponentialBackoffRetry;

import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.concurrent.CountDownLatch;

/**
 * Created by zhuzs on 2017/5/4.
 */
public class CreateOrderNoWithZK {

    private static final String path = "/lock_path";

    public static void main(String[] args) {

        CuratorFramework client = getClient();
        final InterProcessMutex lock = new InterProcessMutex(client, path);
        final CountDownLatch countDownLatch = new CountDownLatch(1);

        final long startTime = new Date().getTime();
        for (int i = 0; i < 10; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        countDownLatch.await();
                        lock.acquire();
                    } catch (Exception e) {
                        e.printStackTrace();
                    }

                    SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd HH:mm:ss|SSS");
                    System.out.println(sdf.format(new Date()));

                    try {
                        lock.release();
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                    System.out.println("顯示此執行緒大概花費時間（等待+執行）:" + (new Date().getTime() - startTime) + "ms");
                }
            }).start();
        }
        System.out.println("建立執行緒花費時間:" + (new Date().getTime() - startTime) + "ms");
        countDownLatch.countDown();
    }

    private static CuratorFramework getClient() {
        RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
        CuratorFramework client = CuratorFrameworkFactory.builder()
                .connectString("127.0.0.1:2181")
                .retryPolicy(retryPolicy)
                .sessionTimeoutMs(6000)
                .connectionTimeoutMs(3000)
                .namespace("demo")
                .build();
        client.start();
        return client;
    }
}

列印結果為：

建立執行緒花費時間:1ms
20170504 19:02:13|178
顯示此執行緒大概花費時間（等待+執行）:210ms
20170504 19:02:13|386
顯示此執行緒大概花費時間（等待+執行）:416ms
20170504 19:02:13|574
顯示此執行緒大概花費時間（等待+執行）:629ms
20170504 19:02:13|660
顯示此執行緒大概花費時間（等待+執行）:678ms
20170504 19:02:13|769
顯示此執行緒大概花費時間（等待+執行）:787ms
20170504 19:02:13|804
顯示此執行緒大概花費時間（等待+執行）:814ms
20170504 19:02:13|851
顯示此執行緒大概花費時間（等待+執行）:881ms
20170504 19:02:13|899
顯示此執行緒大概花費時間（等待+執行）:927ms
20170504 19:02:13|946
顯示此執行緒大概花費時間（等待+執行）:955ms
20170504 19:02:13|976
顯示此執行緒大概花費時間（等待+執行）:993ms

仔細觀察可發現，通過多執行緒的訪問，列印的時間戳卻是唯一的。這裡使用InterProcessMutex類來進行處理分散式鎖，實現了一個生產唯一流水號的功能。

注意事項

在上面的程式碼中，列印了每步操作的時間，其中訪問的zookeeper伺服器是遠端伺服器。從列印的時間我們可以看出，通過這種方式生成唯一流水號並不能支撐很大的併發量。每次操作都需要通過網路訪問，zookeeper的節點操作等，會花費大量的時間。另外，由於精確到毫秒，因此一秒鐘最多也只能處理999個請求。

同時，在分散式環境中上面的示例還是會出現重複的可能性的，比如兩個伺服器的時間不一致，即兩個伺服器相差10ms，恰好第一個執行完，第二個執行的間隙也是10ms，那麼第二個生成的訂單號還是有可能跟第一個重複的，雖然這種概率及其小。

以上通過示例演示了Curator的分散式鎖功能，根據具體的業務需求可選擇不同的業務場景來使用。