分布式鎖實作方式

前言

分享一下分布式鎖

案例介紹

在嘗試了解分布式鎖之前，大家可以想象一下，什麼場景下會使用分布式鎖？

單機應用架構中，秒殺案例使用ReentrantLcok或者synchronized來達到秒殺商品互斥的目的。然而在分布式系統中，會存在多台機器并行去實作同一個功能。也就是說，在多程序中，如果還使用以上JDK提供的程序鎖，來并發通路資料庫資源就可能會出現商品超賣的情況。是以，需要我們來實作自己的分布式鎖。

實作一個分布式鎖應該具備的特性：

• 高可用、高性能的擷取鎖與釋放鎖
• 在分布式系統環境下，一個方法或者變量同一時間隻能被一個線程操作
• 具備鎖失效機制，網絡中斷或當機無法釋放鎖時，鎖必須被删除，防止死鎖
• 具備阻塞鎖特性，即沒有擷取到鎖，則繼續等待擷取鎖
• 具備非阻塞鎖特性，即沒有擷取到鎖，則直接傳回擷取鎖失敗
• 具備可重入特性，一個線程中可以多次擷取同一把鎖，比如一個線程在執行一個帶鎖的方法，該方法中又調用了另一個需要相同鎖的方法，則該線程可以直接執行調用的方法，而無需重新獲得鎖

幾乎很多大型網站及應用都是分布式部署的，分布式場景中的資料一緻性問題一直是一個比較重要的話題。

分布式的CAP理論告訴我們“任何一個分布式系統都無法同時滿足一緻性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance），最多隻能同時滿足兩項

。”是以，很多系統在設計之初就要對這三者做出取舍。在網際網路領域的絕大多數的場景中，

都需要犧牲強一緻性來換取系統的高可用性，系統往往隻需要保證“最終一緻性”

，隻要這個最終時間是在使用者可以接受的範圍内即可。

在很多場景中，

我們為了保證資料的最終一緻性，需要很多的技術方案來支援，比如分布式事務、分布式鎖等。有的時候，我們需要保證一個方法在同一時間内隻能被同一個線程執行

。在單機環境中，Java中其實提供了很多并發處理相關的API，但是這些API在分布式場景中就無能為力了。也就是說單純的Java Api并不能提供分布式鎖的能力。是以針對分布式鎖的實作目前有多種方案。

針對分布式鎖的實作，目前比較常用的有以下幾種方案：

• 基于

  資料庫實作分布式鎖

• 基于

  緩存（redis，memcached，tair）實作分布式鎖

• 基于

  Zookeeper實作分布式

  鎖

前兩種對于分布式生産環境來說并不是特别推薦，高并發下資料庫鎖性能太差，Redis在鎖時間限制和緩存一緻性存在一定問題。最好的方式是用 Zookeeper 如何實作分布式鎖。

在分析這幾種實作方案之前我們先來想一下，我們需要的分布式鎖應該是怎麼樣的？（這裡以方法鎖為例，資源鎖同理）

• 可以保證在分布式部署的應用叢集中，同一個方法在同一時間隻能被一台機器上的一個線程執行。
• 這把鎖要是一把可重入鎖（避免死鎖）
• 這把鎖最好是一把阻塞鎖（根據業務需求考慮要不要這條）
• 有高可用的擷取鎖和釋放鎖功能
• 擷取鎖和釋放鎖的性能要好

基于緩存實作分布式鎖

相比較于基于資料庫實作分布式鎖的方案來說，基于緩存來實作在性能方面會表現的更好一點。而且很多緩存是可以叢集部署的，可以解決單點問題。

目前有很多成熟的緩存産品，包括Redis，memcached以及我們公司内部的Tair。

這裡以Tair為例來分析下使用緩存實作分布式鎖的方案。關于Redis和memcached在網絡上有很多相關的文章，并且也有一些成熟的架構及算法可以直接使用。

基于Tair的實作分布式鎖其實和Redis類似，其中主要的實作方式是使用TairManager.put方法來實作。

以上實作方式同樣存在幾個問題：

1. 這把鎖沒有失效時間，一旦解鎖操作失敗，就會導緻鎖記錄一直在tair中，其他線程無法再獲得到鎖。
2. 這把鎖隻能是非阻塞的，無論成功還是失敗都直接傳回。
3. 這把鎖是非重入的，一個線程獲得鎖之後，在釋放鎖之前，無法再次獲得該鎖，因為使用到的key在tair中已經存在。無法再執行put操作。

當然，同樣有方式可以解決。

• 沒有失效時間？tair的put方法支援傳入失效時間，到達時間之後資料會自動删除。
• 非阻塞？while重複執行。
• 非可重入？在一個線程擷取到鎖之後，把目前主機資訊和線程資訊儲存起來，下次再擷取之前先檢查自己是不是目前鎖的擁有者。

但是，失效時間我設定多長時間為好？如何設定的失效時間太短，方法沒等執行完，鎖就自動釋放了，那麼就會産生并發問題。如果設定的時間太長，其他擷取鎖的線程就可能要平白的多等一段時間。這個問題使用資料庫實作分布式鎖同樣存在

總結

可以使用緩存來代替資料庫來實作分布式鎖，這個可以提供更好的性能，同時，很多緩存服務都是叢集部署的，可以避免單點問題。并且很多緩存服務都提供了可以用來實作分布式鎖的方法，比如Tair的put方法，redis的setnx方法等。并且，這些緩存服務也都提供了對資料的過期自動删除的支援，可以直接設定逾時時間來控制鎖的釋放。

使用緩存實作分布式鎖的優點

• 性能好，實作起來較為友善。

使用緩存實作分布式鎖的缺點

• 通過逾時時間來控制鎖的失效時間并不是十分的靠譜。

基于Zookeeper實作分布式鎖

實作原理

ZooKeeper是一個分布式的，開放源碼的分布式應用程式協調服務，它内部是一個分層的檔案系統目錄樹結構，規定同一個目錄下隻能存在唯一檔案名。

資料模型

• PERSISTENT 持久化節點，節點建立後，不會因為會話失效而消失
• EPHEMERAL 臨時節點， 用戶端session逾時此類節點就會被自動删除
• EPHEMERAL_SEQUENTIAL 臨時自動編号節點
• PERSISTENT_SEQUENTIAL 順序自動編号持久化節點，這種節點會根據目前已存在的節點數自動加 1

螢幕（watcher）

當建立一個節點時，可以注冊一個該節點的螢幕，當節點狀态發生改變時，watch被觸發時，ZooKeeper将會向用戶端發送且僅發送一條通知，因為watch隻能被觸發一次。

根據zookeeper的這些特性，我們來看看如何利用這些特性來實作分布式鎖：

• 建立一個鎖目錄lock
• 線程A擷取鎖會在lock目錄下，建立臨時順序節點
• 擷取鎖目錄下所有的子節點，然後擷取比自己小的兄弟節點，如果不存在，則說明目前線程順序号最小，獲得鎖
• 線程B建立臨時節點并擷取所有兄弟節點，判斷自己不是最小節點，設定監聽(watcher)比自己次小的節點
• 線程A處理完，删除自己的節點，線程B監聽到變更事件，判斷自己是最小的節點，獲得鎖

基于zookeeper臨時有序節點可以實作的分布式鎖。

大緻思想

即為：每個用戶端對某個方法加鎖時，在zookeeper上的與該方法對應的指定節點的目錄下，生成一個唯一的瞬時有序節點。 判斷是否擷取鎖的方式很簡單，隻需要判斷有序節點中序号最小的一個。 當釋放鎖的時候，隻需将這個瞬時節點删除即可。同時，其可以避免服務當機導緻的鎖無法釋放，而産生的死鎖問題。

來看下Zookeeper能不能解決前面提到的問題。

鎖無法釋放？使用Zookeeper可以有效的解決鎖無法釋放的問題，因為在建立鎖的時候，用戶端會在ZK中建立一個臨時節點，一旦用戶端擷取到鎖之後突然挂掉（Session連接配接斷開），那麼這個臨時節點就會自動删除掉。其他用戶端就可以再次獲得鎖。

• 非阻塞鎖？使用Zookeeper可以實作阻塞的鎖，用戶端可以通過在ZK中建立順序節點，并且在節點上綁定監聽器，一旦節點有變化，Zookeeper會通知用戶端，用戶端可以檢查自己建立的節點是不是目前所有節點中序号最小的，如果是，那麼自己就擷取到鎖，便可以執行業務邏輯了。
• 不可重入？使用Zookeeper也可以有效的解決不可重入的問題，用戶端在建立節點的時候，把目前用戶端的主機資訊和線程資訊直接寫入到節點中，下次想要擷取鎖的時候和目前最小的節點中的資料比對一下就可以了。如果和自己的資訊一樣，那麼自己直接擷取到鎖，如果不一樣就再建立一個臨時的順序節點，參與排隊。
• 單點問題？使用Zookeeper可以有效的解決單點問題，ZK是叢集部署的，隻要叢集中有半數以上的機器存活，就可以對外提供服務。

代碼分析

盡管ZooKeeper已經封裝好複雜易出錯的關鍵服務，将簡單易用的接口和性能高效、功能穩定的系統提供給使用者。但是如果讓一個普通開發者去手撸一個分布式鎖還是比較困難的，在秒殺案例中我們直接使用 Apache 開源的curator 開實作 Zookeeper 分布式鎖。

這裡我們使用以下版本，截止目前最新版4.0.1：

<!-- zookeeper 分布式鎖、注意zookeeper版本  這裡對應的是3.4.6-->
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-recipes</artifactId>
    <version>2.10.0</version>
</dependency>
           

首先，我們看下InterProcessLock接口中的幾個方法：

/**
* 擷取鎖、阻塞等待、可重入
*/
public void acquire() throws Exception;

/**
* 擷取鎖、阻塞等待、可重入、逾時則擷取失敗
*/
public boolean acquire(long time, TimeUnit unit) throws Exception;

/**
* 釋放鎖
*/
public void release() throws Exception;

/**
* Returns true if the mutex is acquired by a thread in this JVM
*/
boolean isAcquiredInThisProcess();
           

擷取鎖

//擷取鎖
public void acquire() throws Exception
    {
        if ( !internalLock(-, null) )
        {
            throw new IOException("Lost connection while trying to acquire lock: " + basePath);
        }
    }
           

具體實作

private boolean internalLock(long time, TimeUnit unit) throws Exception
    {
        /*
         實作同一個線程可重入性，如果目前線程已經獲得鎖，
         則增加鎖資料中lockCount的數量(重入次數)，直接傳回成功
        */
        //擷取目前線程
        Thread currentThread = Thread.currentThread();
        //擷取目前線程重入鎖相關資料
        LockData lockData = threadData.get(currentThread);
        if ( lockData != null )
        {
            //原子遞增一個目前值，記錄重入次數，後面鎖釋放會用到
            lockData.lockCount.incrementAndGet();
            return true;
        }
        //嘗試連接配接zookeeper擷取鎖
        String lockPath = internals.attemptLock(time, unit, getLockNodeBytes());
        if ( lockPath != null )
        {
            //建立可重入鎖資料，用于記錄目前線程重入次數
            LockData newLockData = new LockData(currentThread, lockPath);
            threadData.put(currentThread, newLockData);
            return true;
        }
        //擷取鎖逾時或者zk通信異常傳回失敗
        return false;
    }
           

Zookeeper擷取鎖實作：

String attemptLock(long time, TimeUnit unit, byte[] lockNodeBytes) throws Exception
    {    
        //擷取目前時間戳
        final long      startMillis = System.currentTimeMillis();
        //如果unit不為空(非阻塞鎖)，把目前傳入time轉為毫秒
        final Long      millisToWait = (unit != null) ? unit.toMillis(time) : null;
        //子節點辨別
        final byte[]    localLockNodeBytes = (revocable.get() != null) ? new byte[] : lockNodeBytes;

        //嘗試次數
        int             retryCount = ;
        String          ourPath = null;
        boolean         hasTheLock = false;
        boolean         isDone = false;
        //自旋鎖，循環擷取鎖
        while ( !isDone )
        {
            isDone = true;
            try
            {
                //在鎖節點下建立臨時且有序的子節點，例如:_c_008c1b07-d577-4e5f-8699-8f0f98a013b4-lock-000000001
                ourPath = driver.createsTheLock(client, path, localLockNodeBytes);
                //如果目前子節點序号最小，獲得鎖則直接傳回，否則阻塞等待前一個子節點删除通知(release釋放鎖)
                hasTheLock = internalLockLoop(startMillis, millisToWait, ourPath);
            }
            catch ( KeeperException.NoNodeException e )
            {
                //異常處理，如果找不到節點，這可能發生在session過期等時，是以，如果重試允許，隻需重試一次即可
                if ( client.getZookeeperClient().getRetryPolicy().allowRetry(retryCount++, System.currentTimeMillis() - startMillis, RetryLoop.getDefaultRetrySleeper()) )
                {
                    isDone = false;
                }
                else
                {
                    throw e;
                }
            }
        }
        //如果擷取鎖則傳回目前鎖子節點路徑
        if ( hasTheLock )
        {
            return ourPath;
        }
        return null;
    }
           

判斷是否為最小節點：

private boolean internalLockLoop(long startMillis, Long millisToWait, String ourPath) throws Exception
    {
        boolean     haveTheLock = false;
        boolean     doDelete = false;

        try
        {
            if ( revocable.get() != null )
            {
                client.getData().usingWatcher(revocableWatcher).forPath(ourPath);
            }

            //自旋擷取鎖
            while ( (client.getState() == CuratorFrameworkState.STARTED) && !haveTheLock )
            {
                //擷取所有子節點集合
                List<String>        children = getSortedChildren();

                //判斷目前子節點是否為最小子節點
                String              sequenceNodeName = ourPath.substring(basePath.length() + ); // +1 to include the slash

                PredicateResults    predicateResults = driver.getsTheLock(client, children, sequenceNodeName, maxLeases);
                //如果是最小節點則擷取鎖
                if ( predicateResults.getsTheLock() )
                {
                    haveTheLock = true;
                }
                else
                {
                    //擷取前一個節點，用于監聽
                    String  previousSequencePath = basePath + "/" + predicateResults.getPathToWatch();
                    synchronized(this)
                    {
                        try 
                        {
                            //這裡使用getData()接口而不是checkExists()是因為，如果前一個子節點已經被删除了那麼會抛出異常而且不會設定事件監聽器，而checkExists雖然也可以擷取到節點是否存在的資訊但是同時設定了監聽器，這個監聽器其實永遠不會觸發，對于Zookeeper來說屬于資源洩露
                            client.getData().usingWatcher(watcher).forPath(previousSequencePath);
                            if ( millisToWait != null )
                            {
                                millisToWait -= (System.currentTimeMillis() - startMillis);
                                startMillis = System.currentTimeMillis();
                                //如果設定了擷取鎖等待時間
                                if ( millisToWait <=  )
                                {
                                    doDelete = true;    // 逾時則删除子節點
                                    break;
                                }
                                //等待逾時時間
                                wait(millisToWait);
                            }
                            else
                            {
                                wait();//一直等待
                            }
                        }
                        catch ( KeeperException.NoNodeException e ) 
                        {
                            // it has been deleted (i.e. lock released). Try to acquire again
                            //如果前一個子節點已經被删除則deException，隻需要自旋擷取一次即可
                        }
                    }
                }
            }
        }
        catch ( Exception e )
        {
            ThreadUtils.checkInterrupted(e);
            doDelete = true;
            throw e;
        }
        finally
        {
            if ( doDelete )
            {
                deleteOurPath(ourPath);//擷取鎖逾時則删除節點
            }
        }
        return haveTheLock;
    }
           

釋放鎖

public void release() throws Exception
    {
        Thread currentThread = Thread.currentThread();
        LockData lockData = threadData.get(currentThread);
        //沒有擷取鎖，你釋放個球球，如果為空抛出異常
        if ( lockData == null )
        {
            throw new IllegalMonitorStateException("You do not own the lock: " + basePath);
        }
        //擷取重入數量
        int newLockCount = lockData.lockCount.decrementAndGet();
        //如果重入鎖次數大于0，直接傳回
        if ( newLockCount >  )
        {
            return;
        }
        //如果重入鎖次數小于0，抛出異常
        if ( newLockCount <  )
        {
            throw new IllegalMonitorStateException("Lock count has gone negative for lock: " + basePath);
        }
        try
        {
            //釋放鎖
            internals.releaseLock(lockData.lockPath);
        }
        finally
        {
            //移除目前線程鎖資料
            threadData.remove(currentThread);
        }
    }
           

測試案例

/**
 * 基于curator的zookeeper分布式鎖
 */
public class CuratorUtil {
    private static String address = "192.168.1.180:2181";
    public static void main(String[] args) {
        //1、重試政策：初試時間為1s 重試3次
        RetryPolicy retryPolicy = new ExponentialBackoffRetry(, ); 
        //2、通過工廠建立連接配接
        CuratorFramework client = CuratorFrameworkFactory.newClient(address, retryPolicy);
        //3、開啟連接配接
        client.start();
        //4 分布式鎖
        final InterProcessMutex mutex = new InterProcessMutex(client, "/curator/lock"); 
        //讀寫鎖
        //InterProcessReadWriteLock readWriteLock = new InterProcessReadWriteLock(client, "/readwriter");
        ExecutorService fixedThreadPool = Executors.newFixedThreadPool();
        for (int i = ; i < ; i++) {
            fixedThreadPool.submit(new Runnable() {
                @Override
                public void run() {
                    boolean flag = false;
                    try {
                        //嘗試擷取鎖，最多等待5秒
                        flag = mutex.acquire(, TimeUnit.SECONDS);
                        Thread currentThread = Thread.currentThread();
                        if(flag){
                            System.out.println("線程"+currentThread.getId()+"擷取鎖成功");
                        }else{
                            System.out.println("線程"+currentThread.getId()+"擷取鎖失敗");
                        }
                        //模拟業務邏輯，延時4秒
                        Thread.sleep();
                    } catch (Exception e) {
                        e.printStackTrace();
                    } finally{
                        if(flag){
                            try {
                                mutex.release();
                            } catch (Exception e) {
                                e.printStackTrace();
                            }
                        }
                    }
                }
            });
        }
    }
}
           

這裡我們開啟5個線程，每個線程擷取鎖的最大等待時間為5秒，為了模拟具體業務場景，方法中設定4秒等待時間。開始執行main方法，通過ZooInspector監控/curator/lock下的節點如下圖：

對，沒錯，設定4秒的業務處理時長就是為了觀察生成了幾個順序節點。果然如案例中所述，每個線程都會生成一個節點并且還是有序的。

觀察控制台，我們會發現隻有兩個線程擷取鎖成功，另外三個線程逾時擷取鎖失敗會自動删除節點。線程執行完畢我們重新整理一下/curator/lock節點，發現剛才建立的五個子節點已經不存在了。

zookeeper缺點：

使用ZK實作的分布式鎖好像完全符合了本文開頭我們對一個分布式鎖的所有期望。但是，其實并不是，Zookeeper實作的分布式鎖其實存在一個缺點，那就是性能上可能并沒有緩存服務那麼高。因為每次在建立鎖和釋放鎖的過程中，都要動态建立、銷毀瞬時節點來實作鎖功能。ZK中建立和删除節點隻能通過Leader伺服器來執行，然後将資料同不到所有的Follower機器上。

其實，使用Zookeeper也有可能帶來并發問題，隻是并不常見而已。考慮這樣的情況，由于網絡抖動，用戶端可ZK叢集的session連接配接斷了，那麼zk以為用戶端挂了，就會删除臨時節點，這時候其他用戶端就可以擷取到分布式鎖了。就可能産生并發問題。這個問題不常見是因為zk有重試機制，一旦zk叢集檢測不到用戶端的心跳，就會重試，Curator用戶端支援多種重試政策。多次重試之後還不行的話才會删除臨時節點。（是以，選擇一個合适的重試政策也比較重要，要在鎖的粒度和并發之間找一個平衡。）

總結

使用Zookeeper實作分布式鎖的優點

• 有效的解決單點問題，不可重入問題，非阻塞問題以及鎖無法釋放的問題。實作起來較為簡單。

使用Zookeeper實作分布式鎖的缺點

• 性能上不如使用緩存實作分布式鎖。 需要對ZK的原理有所了解。

基于資料庫實作分布式鎖

基于資料庫表

要實作分布式鎖，最簡單的方式可能就是直接建立一張鎖表，然後通過操作該表中的資料來實作了。

當我們要鎖住某個方法或資源時，我們就在該表中增加一條記錄，想要釋放鎖的時候就删除這條記錄。

建立這樣一張資料庫表：

當我們想要鎖住某個方法時，執行以下SQL：

因為我們對method_name做了唯一性限制，這裡如果有多個請求同時送出到資料庫的話，資料庫會保證隻有一個操作可以成功，那麼我們就可以認為操作成功的那個線程獲得了該方法的鎖，可以執行方法體内容。

當方法執行完畢之後，想要釋放鎖的話，需要執行以下Sql:

上面這種簡單的實作有以下幾個問題：

1. 這把鎖強依賴資料庫的可用性，資料庫是一個單點，一旦資料庫挂掉，會導緻業務系統不可用。
2. 這把鎖沒有失效時間，一旦解鎖操作失敗，就會導緻鎖記錄一直在資料庫中，其他線程無法再獲得到鎖。
3. 這把鎖隻能是非阻塞的，因為資料的insert操作，一旦插入失敗就會直接報錯。沒有獲得鎖的線程并不會進入排隊隊列，要想再次獲得鎖就要再次觸發獲得鎖操作。
4. 這把鎖是非重入的，同一個線程在沒有釋放鎖之前無法再次獲得該鎖。因為資料中資料已經存在了。

當然，我們也可以有其他方式解決上面的問題。

1. 資料庫是單點？搞兩個資料庫，資料之前雙向同步。一旦挂掉快速切換到備庫上。
2. 沒有失效時間？隻要做一個定時任務，每隔一定時間把資料庫中的逾時資料清理一遍。
3. 非阻塞的？搞一個while循環，直到insert成功再傳回成功。
4. 非重入的？在資料庫表中加個字段，記錄目前獲得鎖的機器的主機資訊和線程資訊，那麼下次再擷取鎖的時候先查詢資料庫，如果目前機器的主機資訊和線程資訊在資料庫可以查到的話，直接把鎖配置設定給他就可以了。

基于資料庫排他鎖

除了可以通過增删操作資料表中的記錄以外，其實還可以借助資料中自帶的鎖來實作分布式的鎖。

我們還用剛剛建立的那張資料庫表。可以通過資料庫的排他鎖來實作分布式鎖。 基于MySql的InnoDB引擎，可以使用以下方法來實作加鎖操作：

在查詢語句後面增加for update，資料庫會在查詢過程中給資料庫表增加排他鎖（這裡再多提一句，InnoDB引擎在加鎖的時候，隻有通過索引進行檢索的時候才會使用行級鎖，否則會使用表級鎖。這裡我們希望使用行級鎖，就要給method_name添加索引，值得注意的是，這個索引一定要建立成唯一索引，否則會出現多個重載方法之間無法同時被通路的問題。重載方法的話建議把參數類型也加上。）。當某條記錄被加上排他鎖之後，其他線程無法再在該行記錄上增加排他鎖。

我們可以認為獲得排它鎖的線程即可獲得分布式鎖，當擷取到鎖之後，可以執行方法的業務邏輯，執行完方法之後，再通過以下方法解鎖：

通過connection.commit()操作來釋放鎖。

這種方法可以有效的解決上面提到的無法釋放鎖和阻塞鎖的問題。

• 阻塞鎖？ for update語句會在執行成功後立即傳回，在執行失敗時一直處于阻塞狀态，直到成功。
• 鎖定之後服務當機，無法釋放？使用這種方式，服務當機之後資料庫會自己把鎖釋放掉。
• 但是還是無法直接解決資料庫單點和可重入問題。

這裡還可能存在另外一個問題，雖然我們對method_name 使用了唯一索引，并且顯示使用for update來使用行級鎖。但是，MySql會對查詢進行優化，即便在條件中使用了索引字段，但是否使用索引來檢索資料是由 MySQL 通過判斷不同執行計劃的代價來決定的，如果 MySQL 認為全表掃效率更高，比如對一些很小的表，它就不會使用索引，這種情況下 InnoDB 将使用表鎖，而不是行鎖。如果發生這種情況就悲劇了。。。

還有一個問題，就是我們要使用排他鎖來進行分布式鎖的lock，那麼一個排他鎖長時間不送出，就會占用資料庫連接配接。一旦類似的連接配接變得多了，就可能把資料庫連接配接池撐爆

總結

總結一下使用資料庫來實作分布式鎖的方式，這兩種方式都是依賴資料庫的一張表，一種是通過表中的記錄的存在情況确定目前是否有鎖存在，另外一種是通過資料庫的排他鎖來實作分布式鎖。

資料庫實作分布式鎖的優點

• 直接借助資料庫，容易了解。

資料庫實作分布式鎖的缺點

• 會有各種各樣的問題，在解決問題的過程中會使整個方案變得越來越複雜。
• 操作資料庫需要一定的開銷，性能問題需要考慮。
• 使用資料庫的行級鎖并不一定靠譜，尤其是當我們的鎖表并不大的時候。

三種方案的比較

上面幾種方式，哪種方式都無法做到完美。就像CAP一樣，在複雜性、可靠性、性能等方面無法同時滿足，是以，根據不同的應用場景選擇最适合自己的才是王道。

• 從了解的難易程度角度（從低到高）

  資料庫 > 緩存 > Zookeeper

• 從實作的複雜性角度（從低到高）

  Zookeeper >= 緩存 > 資料庫

• 從性能角度（從高到低）

  緩存 > Zookeeper >= 資料庫

• 從可靠性角度（從高到低）

  Zookeeper > 緩存 > 資料庫