分散式鎖應該具備哪些條件 在分析分散式鎖的三種實現方式之前,先了解一下分散式鎖應該具備哪些條件:

1、在分散式系統環境下,一個方法在同一時間只能被一個機器的一個執行緒執行;  2、高可用的獲取鎖與釋放鎖;  3、高效能的獲取鎖與釋放鎖;  4、具備可重入特性;  5、具備鎖失效機制,防止死鎖;  6、具備非阻塞鎖特性,即沒有獲取到鎖將直接返回獲取鎖失敗。

三、分散式鎖的三種實現方式 目前幾乎很多大型網站及應用都是分散式部署的,分散式場景中的資料一致性問題一直是一個比較重要的話題。分散式的CAP理論告訴我們“任何一個分散式系統都無法同時滿足一致性(Consistency)、可用性(Availability)和分割槽容錯性(Partition tolerance),最多隻能同時滿足兩項。”所以,很多系統在設計之初就要對這三者做出取捨。在網際網路領域的絕大多數的場景中,都需要犧牲強一致性來換取系統的高可用性,系統往往只需要保證“最終一致性”,只要這個最終時間是在使用者可以接受的範圍內即可。

在很多場景中,我們為了保證資料的最終一致性,需要很多的技術方案來支援,比如分散式事務、分散式鎖等。有的時候,我們需要保證一個方法在同一時間內只能被同一個執行緒執行。

基於資料庫實現分散式鎖;  基於快取(Redis等)實現分散式鎖;  基於Zookeeper實現分散式鎖;

儘管有這三種方案,但是不同的業務也要根據自己的情況進行選型,他們之間沒有最好只有更適合!

四、基於資料庫的實現方式 基於資料庫的實現方式的核心思想是:在資料庫中建立一個表,表中包含方法名等欄位,並在方法名欄位上建立唯一索引,想要執行某個方法,就使用這個方法名向表中插入資料,成功插入則獲取鎖,執行完成後刪除對應的行資料釋放鎖。

(1)建立一個表:

DROP TABLE IF EXISTS `method_lock`; CREATE TABLE `method_lock` (   `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵',   `method_name` varchar(64) NOT NULL COMMENT '鎖定的方法名',   `desc` varchar(255) NOT NULL COMMENT '備註資訊',   `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,   PRIMARY KEY (`id`),   UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='鎖定中的方法'; 1 2 3 4 5 6 7 8 9

(2)想要執行某個方法,就使用這個方法名向表中插入資料:

INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '測試的methodName'); 1 因為我們對method_name做了唯一性約束,這裡如果有多個請求同時提交到資料庫的話,資料庫會保證只有一個操作可以成功,那麼我們就可以認為操作成功的那個執行緒獲得了該方法的鎖,可以執行方法體內容。

(3)成功插入則獲取鎖,執行完成後刪除對應的行資料釋放鎖:

delete from method_lock where method_name ='methodName'; 1 注意:這只是使用基於資料庫的一種方法,使用資料庫實現分散式鎖還有很多其他的玩法!

使用基於資料庫的這種實現方式很簡單,但是對於分散式鎖應該具備的條件來說,它有一些問題需要解決及優化:

1、因為是基於資料庫實現的,資料庫的可用性和效能將直接影響分散式鎖的可用性及效能,所以,資料庫需要雙機部署、資料同步、主備切換;

2、不具備可重入的特性,因為同一個執行緒在釋放鎖之前,行資料一直存在,無法再次成功插入資料,所以,需要在表中新增一列,用於記錄當前獲取到鎖的機器和執行緒資訊,在再次獲取鎖的時候,先查詢表中機器和執行緒資訊是否和當前機器和執行緒相同,若相同則直接獲取鎖;

3、沒有鎖失效機制,因為有可能出現成功插入資料後,伺服器宕機了,對應的資料沒有被刪除,當服務恢復後一直獲取不到鎖,所以,需要在表中新增一列,用於記錄失效時間,並且需要有定時任務清除這些失效的資料;

4、不具備阻塞鎖特性,獲取不到鎖直接返回失敗,所以需要優化獲取邏輯,迴圈多次去獲取。

5、在實施的過程中會遇到各種不同的問題,為了解決這些問題,實現方式將會越來越複雜;依賴資料庫需要一定的資源開銷,效能問題需要考慮。

五、基於Redis的實現方式 1、選用Redis實現分散式鎖原因:

(1)Redis有很高的效能;  (2)Redis命令對此支援較好,實現起來比較方便

2、使用命令介紹:

(1)SETNX

SETNX key val:當且僅當key不存在時,set一個key為val的字串,返回1;若key存在,則什麼都不做,返回0。 1 (2)expire

expire key timeout:為key設定一個超時時間,單位為second,超過這個時間鎖會自動釋放,避免死鎖。 1 (3)delete

delete key:刪除key 1 在使用Redis實現分散式鎖的時候,主要就會使用到這三個命令。

3、實現思想:

(1)獲取鎖的時候,使用setnx加鎖,並使用expire命令為鎖新增一個超時時間,超過該時間則自動釋放鎖,鎖的value值為一個隨機生成的UUID,通過此在釋放鎖的時候進行判斷。

(2)獲取鎖的時候還設定一個獲取的超時時間,若超過這個時間則放棄獲取鎖。

(3)釋放鎖的時候,通過UUID判斷是不是該鎖,若是該鎖,則執行delete進行鎖釋放。

4、 分散式鎖的簡單實現程式碼:

/**  * 分散式鎖的簡單實現程式碼  * Created by liuyang on 2017/4/20.  */ public class DistributedLock {

    private final JedisPool jedisPool;

    public DistributedLock(JedisPool jedisPool) {         this.jedisPool = jedisPool;     }

    /**      * 加鎖      * @param lockName       鎖的key      * @param acquireTimeout 獲取超時時間      * @param timeout        鎖的超時時間      * @return 鎖標識      */     public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) {         Jedis conn = null;         String retIdentifier = null;         try {             // 獲取連線             conn = jedisPool.getResource();             // 隨機生成一個value             String identifier = UUID.randomUUID().toString();             // 鎖名,即key值             String lockKey = "lock:" + lockName;             // 超時時間,上鎖後超過此時間則自動釋放鎖             int lockExpire = (int) (timeout / 1000);

            // 獲取鎖的超時時間,超過這個時間則放棄獲取鎖             long end = System.currentTimeMillis() + acquireTimeout;             while (System.currentTimeMillis() < end) {                 if (conn.setnx(lockKey, identifier) == 1) {                     conn.expire(lockKey, lockExpire);                     // 返回value值,用於釋放鎖時間確認                     retIdentifier = identifier;                     return retIdentifier;                 }                 // 返回-1代表key沒有設定超時時間,為key設定一個超時時間                 if (conn.ttl(lockKey) == -1) {                     conn.expire(lockKey, lockExpire);                 }

                try {                     Thread.sleep(10);                 } catch (InterruptedException e) {                     Thread.currentThread().interrupt();                 }             }         } catch (JedisException e) {             e.printStackTrace();         } finally {             if (conn != null) {                 conn.close();             }         }         return retIdentifier;     }

    /**      * 釋放鎖      * @param lockName   鎖的key      * @param identifier 釋放鎖的標識      * @return      */     public boolean releaseLock(String lockName, String identifier) {         Jedis conn = null;         String lockKey = "lock:" + lockName;         boolean retFlag = false;         try {             conn = jedisPool.getResource();             while (true) {                 // 監視lock,準備開始事務                 conn.watch(lockKey);                 // 通過前面返回的value值判斷是不是該鎖,若是該鎖,則刪除,釋放鎖                 if (identifier.equals(conn.get(lockKey))) {                     Transaction transaction = conn.multi();                     transaction.del(lockKey);                     List<Object> results = transaction.exec();                     if (results == null) {                         continue;                     }                     retFlag = true;                 }                 conn.unwatch();                 break;             }         } catch (JedisException e) {             e.printStackTrace();         } finally {             if (conn != null) {                 conn.close();             }         }         return retFlag;     } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 5、測試剛才實現的分散式鎖

例子中使用50個執行緒模擬秒殺一個商品,使用–運算子來實現商品減少,從結果有序性就可以看出是否為加鎖狀態。

模擬秒殺服務,在其中配置了jedis執行緒池,在初始化的時候傳給分散式鎖,供其使用。

/**  * Created by liuyang on 2017/4/20.  */ public class Service {

    private static JedisPool pool = null;

    private DistributedLock lock = new DistributedLock(pool);

    int n = 500;

    static {         JedisPoolConfig config = new JedisPoolConfig();         // 設定最大連線數         config.setMaxTotal(200);         // 設定最大空閒數         config.setMaxIdle(8);         // 設定最大等待時間         config.setMaxWaitMillis(1000 * 100);         // 在borrow一個jedis例項時,是否需要驗證,若為true,則所有jedis例項均是可用的         config.setTestOnBorrow(true);         pool = new JedisPool(config, "127.0.0.1", 6379, 3000);     }

    public void seckill() {         // 返回鎖的value值,供釋放鎖時候進行判斷         String identifier = lock.lockWithTimeout("resource", 5000, 1000);         System.out.println(Thread.currentThread().getName() + "獲得了鎖");         System.out.println(--n);         lock.releaseLock("resource", identifier);     } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 模擬執行緒進行秒殺服務:

public class ThreadA extends Thread {     private Service service;

    public ThreadA(Service service) {         this.service = service;     }

    @Override     public void run() {         service.seckill();     } }

public class Test {     public static void main(String[] args) {         Service service = new Service();         for (int i = 0; i < 50; i++) {             ThreadA threadA = new ThreadA(service);             threadA.start();         }     } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 結果如下,結果為有序的:

若註釋掉使用鎖的部分:

public void seckill() {     // 返回鎖的value值,供釋放鎖時候進行判斷     //String indentifier = lock.lockWithTimeout("resource", 5000, 1000);     System.out.println(Thread.currentThread().getName() + "獲得了鎖");     System.out.println(--n);     //lock.releaseLock("resource", indentifier); } 1 2 3 4 5 6 7 從結果可以看出,有一些是非同步進行的:

5、基於ZooKeeper的實現方式 ZooKeeper是一個為分散式應用提供一致性服務的開源元件,它內部是一個分層的檔案系統目錄樹結構,規定同一個目錄下只能有一個唯一檔名。基於ZooKeeper實現分散式鎖的步驟如下:

(1)建立一個目錄mylock;  (2)執行緒A想獲取鎖就在mylock目錄下建立臨時順序節點;  (3)獲取mylock目錄下所有的子節點,然後獲取比自己小的兄弟節點,如果不存在,則說明當前執行緒順序號最小,獲得鎖;  (4)執行緒B獲取所有節點,判斷自己不是最小節點,設定監聽比自己次小的節點;  (5)執行緒A處理完,刪除自己的節點,執行緒B監聽到變更事件,判斷自己是不是最小的節點,如果是則獲得鎖。

這裡推薦一個Apache的開源庫Curator,它是一個ZooKeeper客戶端,Curator提供的InterProcessMutex是分散式鎖的實現,acquire方法用於獲取鎖,release方法用於釋放鎖。

優點:具備高可用、可重入、阻塞鎖特性,可解決失效死鎖問題。

缺點:因為需要頻繁的建立和刪除節點,效能上不如Redis方式。

6、總結 上面的三種實現方式,沒有在所有場合都是完美的,所以,應根據不同的應用場景選擇最適合的實現方式。

在分散式環境中,對資源進行上鎖有時候是很重要的,比如搶購某一資源,這時候使用分散式鎖就可以很好地控制資源。  當然,在具體使用中,還需要考慮很多因素,比如超時時間的選取,獲取鎖時間的選取對併發量都有很大的影響,上述實現的分散式鎖也只是一種簡單的實現,主要是一種思想,以上包括文中的程式碼可能並不適用於正式的生產環境,只做入門參考! ---------------------  作者:徐劉根  來源:CSDN  原文:https://blog.csdn.net/xlgen157387/article/details/79036337  版權宣告:本文為博主原創文章,轉載請附上博文連結!