2. 程式人生 > >從構建分布式秒殺系統聊聊分布式鎖

從構建分布式秒殺系統聊聊分布式鎖

阿新 • • 發佈：2018-08-01
調用 you tel bre policy 學習 感悟 ant 操作

技術分享圖片

前言

最近懶成一坨屎，學不動系列一波接一波，大多還都是底層原理相關的。上周末抽時間重讀了周誌明大濕的 JVM 高效並發部分，每讀一遍都有不同的感悟。路漫漫，借此，把前段時間搞著玩的秒殺案例中的分布式鎖深入了解一下。

案例介紹

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

技術分享圖片

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

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

  • 高可用、高性能的獲取鎖與釋放鎖

  • 在分布式系統環境下，一個方法或者變量同一時間只能被一個線程操作

  • 具備鎖失效機制，網絡中斷或宕機無法釋放鎖時，鎖必須被刪除，防止死鎖

  • 具備阻塞鎖特性，即沒有獲取到鎖，則繼續等待獲取鎖

  • 具備非阻塞鎖特性，即沒有獲取到鎖，則直接返回獲取鎖失敗

  • 具備可重入特性，一個線程中可以多次獲取同一把鎖，比如一個線程在執行一個帶鎖的方法，該方法中又調用了另一個需要相同鎖的方法，則該線程可以直接執行調用的方法，而無需重新獲得鎖

在之前的秒殺案例中，我們曾介紹過關於分布式鎖幾種實現方式：

  • 基於數據庫實現分布式鎖
  • 基於 Redis 實現分布式鎖
  • 基於 Zookeeper 實現分布式鎖

前兩種對於分布式生產環境來說並不是特別推薦，高並發下數據庫鎖性能太差，Redis在鎖時間限制和緩存一致性存在一定問題。這裏我們重點介紹一下 Zookeeper 如何實現分布式鎖。

實現原理

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

技術分享圖片

數據模型

  • PERSISTENT 持久化節點，節點創建後，不會因為會話失效而消失

  • EPHEMERAL 臨時節點， 客戶端session超時此類節點就會被自動刪除

  • EPHEMERAL_SEQUENTIAL 臨時自動編號節點

  • PERSISTENT_SEQUENTIAL 順序自動編號持久化節點，這種節點會根據當前已存在的節點數自動加 1

監視器（watcher）

當創建一個節點時，可以註冊一個該節點的監視器，當節點狀態發生改變時，watch被觸發時，ZooKeeper將會向客戶端發送且僅發送一條通知，因為watch只能被觸發一次。

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

  • 創建一個鎖目錄lock

  • 線程A獲取鎖會在lock目錄下，創建臨時順序節點

  • 獲取鎖目錄下所有的子節點，然後獲取比自己小的兄弟節點，如果不存在，則說明當前線程順序號最小，獲得鎖

  • 線程B創建臨時節點並獲取所有兄弟節點，判斷自己不是最小節點，設置監聽(watcher)比自己次小的節點（只關註比自己次小的節點是為了防止發生“羊群效應”）

  • 線程A處理完，刪除自己的節點，線程B監聽到變更事件，判斷自己是最小的節點，獲得鎖

代碼分析

盡管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(-1, 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[0] : lockNodeBytes;
        //嘗試次數
        int             retryCount = 0;

        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); // +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 <= 0 )
                                {
                                    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 > 0 )
        {
            return;
        }
        //如果重入鎖次數小於0，拋出異常
        if ( newLockCount < 0 )
        {
            throw new IllegalMonitorStateException("Lock count has gone negative for lock: " + basePath);
        }
        try
        {
            //釋放鎖
            internals.releaseLock(lockData.lockPath);
        }
        finally
        {
            //移除當前線程鎖數據
            threadData.remove(currentThread);
        }
    }

測試案例

為了更好的理解其原理和代碼分析中獲取鎖的過程，這裏我們實現一個簡單的Demo：

/**
 * 基於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(1000, 3); 
        //2、通過工廠創建連接
        CuratorFramework client = CuratorFrameworkFactory.newClient(address, retryPolicy);
        //3、開啟連接
        client.start();
        //4 分布式鎖
        final InterProcessMutex mutex = new InterProcessMutex(client, "/curator/lock"); 
        //讀寫鎖
        //InterProce***eadWriteLock readWriteLock = new InterProce***eadWriteLock(client, "/readwriter");

        ExecutorService fixedThreadPool = Executors.newFixedThreadPool(5);

        for (int i = 0; i < 5; i++) {
            fixedThreadPool.submit(new Runnable() {
                @Override
                public void run() {
                    boolean flag = false;
                    try {
                        //嘗試獲取鎖，最多等待5秒
                        flag = mutex.acquire(5, TimeUnit.SECONDS);
                        Thread currentThread = Thread.currentThread();
                        if(flag){
                            System.out.println("線程"+currentThread.getId()+"獲取鎖成功");
                        }else{
                            System.out.println("線程"+currentThread.getId()+"獲取鎖失敗");
                        }
                        //模擬業務邏輯，延時4秒
                        Thread.sleep(4000);
                    } 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節點，發現剛才創建的五個子節點已經不存在了。

小結

通過分析第三方開源工具實現的分布式鎖方式，收獲還是滿滿的。學習本身就是一個由淺入深的過程，從如何調用API，到理解其代碼邏輯實現，想要更深入可以去挖掘Zookeeper的核心算法ZAB協議。

最後為了方便大家學習，總結了學習過程中遇到的幾個關鍵詞：重入鎖、自旋鎖、有序節點、阻塞、非阻塞、監聽，希望對大家有所幫助。

秒殺案例：https://gitee.com/52itstyle/spring-boot-seckill

參考

https://yq.aliyun.com/articles/60663

http://www.hollischuang.com/archives/1716

http://www.cnblogs.com/sunddenly/p/4033574.html

http://ifeve.com/zookeeper-lock/

https://blog.52itstyle.com/archives/3202/

從構建分布式秒殺系統聊聊分布式鎖

相關推薦

從構建分布式秒殺系統聊聊分布式鎖

調用 you tel bre policy 學習 感悟 ant 操作 前言 最近懶成一坨屎，學不動系列一波接一波，大多還都是底層原理相關的。上周末抽時間重讀了周誌明大濕的 JVM 高效並發部分，每讀一遍都有不同的感悟。路漫漫，借此，把前段時間搞著玩的秒殺案例中的分布式鎖深

從構建分布式秒殺系統聊聊Lock鎖使用中的坑

Lock 事物 秒殺 前言 在單體架構的秒殺活動中，為了減輕DB層的壓力，這裏我們采用了Lock鎖來實現秒殺用戶排隊搶購。然而很不幸的是盡管使用了鎖，但是測試過程中仍然會超賣，執行了N多次發現依然有問題。輸出一下代碼吧，可能大家看的比較真切： @Service("seckillService")

從構建分布式秒殺系統聊聊限流的多種實現

秒殺 限流 分布式 OpenResty 前言 俗話說的好，冰凍三尺非一日之寒，滴水穿石非一日之功，羅馬也不是一天就建成的。兩周前秒殺案例初步成型，分享到了中國最大的同×××友網站-碼雲。同時也收到了不少小夥伴的建議和投訴。我從不認為分布式、集群、秒殺這些就應該是大廠的專利，在互聯網的今天無論

從構建分布式秒殺系統聊聊WebSocket推送通知

shadow [1] 小夥伴 ref 相關 消費 png 重試 們的 前言 秒殺架構到後期，我們采用了消息隊列的形式實現搶購邏輯，那麽之前拋出過這樣一個問題：消息隊列異步處理完每個用戶請求後，如何通知給相應用戶秒殺成功？ 場景映射 首先，我們舉一個生活中比較常見的例子：我

從構建分布式秒殺系統聊聊驗證碼

什麽 全面 ror thead 羊毛黨 51cto ring class word 前言 為了攔截大部分請求，秒殺案例前端引入了驗證碼。淘寶上很多人吐槽，等輸入完秒殺活動結束了，對，結束了...... 當然了，驗證碼的真正作用是，有效攔截刷單操作，讓羊毛黨空手而歸。 驗證

SpringBoot開發案例從0到1構建分布式秒殺系統

SpringBoot redis kafka 秒殺 前言 最近，被推送了不少秒殺架構的文章，忙裏偷閑自己也總結了一下互聯網平臺秒殺架構設計，當然也借鑒了不少同學的思路。俗話說，脫離案例講架構都是耍流氓，最終使用SpringBoot模擬實現了部分秒殺場景，同時跟大家分享交流一下。 秒殺場景 秒

從構建分散式秒殺系統聊聊Disruptor高效能佇列

前言 秒殺架構持續優化中，基於自身認知不足之處在所難免，也請大家指正，共同進步。文章標題來自碼友的建議，希望可以把阻塞佇列ArrayBlockingQueue這個佇列替換成Disruptor，由於之前曾接觸過這個東西，聽說很不錯，正好藉此機會整合進來。 簡介 LMAX

從構建分散式秒殺系統聊聊WebSocket推送通知

前言 秒殺架構到後期，我們採用了訊息佇列的形式實現搶購邏輯，那麼之前丟擲過這樣一個問題：訊息佇列非同步處理完每個使用者請求後，如何通知給相應使用者秒殺成功？ 場景對映 首先，我們舉一個生活中比較常見的例子：我們去銀行辦理業務，一般會選擇相關業務列印一個排號紙，然後就

從構建分散式秒殺系統聊聊驗證碼

前言 為了攔截大部分請求，秒殺案例前端引入了驗證碼。淘寶上很多人吐槽，等輸入完秒殺活動結束了，對，結束了...... 當然了，驗證碼的真正作用是，有效攔截刷單操作，讓羊毛黨空手而歸。 驗證碼 那麼到底什麼是驗證碼呢？驗證碼作為一種人機識別手段，其終極目的，就是區分正常人和機器的操作。我們常見的網際網路註冊、

從構建分散式秒殺系統聊聊限流特技 侵立刪

轉自：https://mp.weixin.qq.com/s/Jgp4KCRmuqVp6W6nd3Bxtw 前言 俗話說的好，冰凍三尺非一日之寒，滴水穿石非一日之功，羅馬也不是一天就建成的。兩週前秒殺案例初步成型，分享到了中國最大的同性交友網站-碼雲。同時也收到了不

從構建分散式秒殺系統聊聊限流特技

前言俗話說的好，冰凍三尺非一日之寒，滴水穿石非一日之功，羅馬也不是一天就建成的。兩週前秒殺案例初步成型，分享到了中國最大的同性交友網站-碼雲。同時也收到了不少小夥伴的建議和投訴。我從不認為分散式、叢集、秒殺這些就應該是大廠的專利，在網際網路的今天無論什麼時候都要時刻武裝自己，

分布式鎖-----秒殺系統

png off cat 當前 try 分布式鎖 lee framework tar 1.ZK import org.apache.curator.RetryPolicy; import org.apache.curator.framework.CuratorFramew

從零開始，如何設計一個“秒殺”系統

秒殺”，就是在同一個時刻有大量請求爭搶購買同一個商品，並完成交易的過程，其間涉及大量的併發讀和併發寫，並要求高可靠和高效能的系統支援。 也因此，“秒殺”對於程式設計師來講也意味著巨大的挑戰。如何讓系統面對百萬級的請求流量不出故障？如何保證高併發情況下資料的一致性寫？如何在不堆伺服器的情況下應對是

從無到有構建億級微服務秒殺系統

解決方案 工業 可用 學員 人才 業界 query 支付寶 myba 從無到有構建億級微服務秒殺系統（真實工業界案例） 題取馬：zuoz 課成滴誌：：https://pan.baidu.com/s/1yiNyYTbqMG4PWC4XBoYmJg 錄制本套教程的初衷，通過從

《大型網站技術架構：核心原理與案例分析》-- 讀書筆記 (5) ：網購秒殺系統

案例 並發 刷新 隨機 url 對策 -- 技術 動態生成 1. 秒殺活動的技術挑戰及應對策略 1.1 對現有網站業務造成沖擊 秒殺活動具有時間短，並發訪問量大的特點，必然會對現有業務造成沖擊。對策：秒殺系統獨立部署 1.2 高並發下的應用、

用Redis輕松實現秒殺系統

tar 幫助 說過 腳本 .net 所有 paxos 你會 用戶 秒殺系統的架構設計 秒殺系統，是典型的短時大量突發訪問類問題。對這類問題，有三種優化性能的思路： 寫入內存而不是寫入硬盤 異步處理而不是同步處理 分布式處理 用上這三招，不論秒殺時負載多大，都能輕松應對。

SSM實戰——秒殺系統前言

str 項目 簡單使用 http spring boot ear 瓶頸 ice 項目來源：慕課網 http://www.imooc.com/learn/587 項目開發流程：整合SSM框架——項目需求分析與實現——解決高並發優化 所用技術： Maven：框架依賴包管理 My

看秒殺系統的時候看到的關於並發隊列的介紹，摘抄如下

有效 初始 預處理 模塊 數組 ext utf 感覺 寫入 並發隊列的選擇 Java的並發包提供了三個常用的並發隊列實現，分別是：ArrayBlockingQueue、ConcurrentLinkedQueue 和 LinkedBlockingQueue 。

秒殺系統架構優化思路

沒有 bsp 認證 mis red src 系統 如果 所有 一、為什麽難 秒殺系統難做的原因：庫存只有一份，所有人會在集中的時間讀和寫這些數據。 例如小米手機每周二的秒殺，可能手機只有1萬部，但瞬時進入的流量可能是幾百幾千萬。 又例如12306搶票，亦與秒殺類似，瞬時流量

秒殺系統架構分析與實戰

選擇 return 暫時 memcached something 關心 附加 ron sta 1 秒殺業務分析 正常電子商務流程（1）查詢商品；（2）創建訂單；（3）扣減庫存；（4）更新訂單；（5）付款；（6）賣家發貨 秒殺業務的特性（1）低廉價格；（2）大幅推廣；