集群多JVM分布式鎖實現

基於數據庫表樂觀鎖 (基本廢棄)

要實現分布式鎖，最簡單的⽅方式可能就是直接創建⼀一張鎖表，然后通過操作該表中的數據來實現了了。
當我們要鎖住某個⽅法或資源時，我們就在該表中增加一條記錄，想要釋放鎖的時候就刪除這條記錄。
比如創建這樣一張數據庫表:

CREATE TABLE `methodLock` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
`method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '鎖定的⽅方法名', `desc` varchar(1024) NOT NULL DEFAULT '備注信息',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存數據時間，⾃自動⽣生成',
PRIMARY KEY (`id`),
UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='鎖定中的⽅方法';

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

insert into methodLock(method_name,desc) values (‘method_name’,‘desc’)

因為我們對method_name做了唯一性約束，這里如果有多個請求同時提交到數據庫的話，數據庫會保證只有一個操作可以成功，那么我們就可以認為操作成功的那個線程獲得了該方法的鎖，可以執方法體內容。
當⽅法執行完畢之后，想要釋放鎖的話，需要執⾏行行以下sql:

delete from methodLock where method_name ='method_name'

上面說到這種方式基本廢棄，那么這種簡單的實現會存在哪些問題呢？

1. 這把鎖會強依賴數據庫的可用性，數據庫是一個單點，⼀旦數據庫掛掉，會導致業務系統不可⽤。
2. 這把鎖並沒有失效時間，⼀旦解鎖操作失敗，就會導致鎖記錄一直存在數據庫中，其它線程無法再獲得到鎖。
3. 這把鎖只能是非阻塞的，因為數據的insert操作，⼀旦插⼊入失敗就會直接報錯。沒有獲得鎖的線程並不會進入排隊列，要想再次獲得鎖就要再次觸發獲得鎖操作。
4. 這把鎖是非重⼊的，同⼀個線程在沒有釋放鎖之前無法再次獲得該鎖。因為數據已經存在了。當然，我們也可以有其它方式解決上面的問題。

• 針對數據庫是單點問題搞兩個數據庫，數據之前雙向同步。⼀旦掛掉快速切換到備庫上。
• 針對沒有失效時間?我們可以做一個定時任務，每隔一定時間把數據庫中的超時數據清理理一遍。
• 針對非阻塞的?搞⼀個自旋while循環，直到insert成功再返回成功。
• 針對⾮重入的?我們可以在數據庫表中加個字段，記錄當前獲得鎖的機器的主機信息和線程信息，那么下次再獲取鎖的時候先查詢數據庫，如果當前機器的主機信息和線程信息在數據庫可以查到的話，直接把鎖分配給他就可以了。
• 基於數據庫排他鎖 除了可以通過增刪操作數據表中的記錄以外，其實還可以借助數據中自帶的鎖來實現分布式的鎖。我們⽤剛剛創建的那張數據庫表。可以通過數據庫的排他鎖來實現分布式鎖。 基於MySql的InnoDB 引擎，可以使用以下方法來實現加鎖操作。
  偽代碼如下：

public boolean lock(){
    connection.setAutoCommit(false)
    while(true){
        try{
            result = select * from methodLock where method_name=xxx
            for update;
            if(result==null){
                return true;
            }
        }catch(Exception e){
}
        sleep(1000);
    }
    return false;
}

在查詢語句后⾯增加for update，數據庫會在查詢過程中給數據庫表增加排他鎖。當某條記錄被加上排他鎖之后，其他線程將無法再在該行行記錄上增加排他鎖。
我們可以認為獲得排它鎖的線程即可獲得分布式鎖，當獲取到鎖之后，可以執⾏方法的業務邏輯，執行完之后，通過connection.commit()操作來釋放鎖。 這種方法可以有效的解決上⾯提到的⽆法釋放鎖和阻塞鎖的問題。
阻塞鎖? for update語句會在執行成功后⽴即返回，在執行失敗時⼀直處於阻塞狀態，直到成功。鎖定之后 服務宕機，⽆法釋放?使⽤這種⽅式，服務宕機之后數據庫會自己把鎖釋放掉。但是還是⽆法直接解決數據庫單點和可重⼊問題。

 public void unlock(){
    connection.commit();
}

說了這么多，我們總結下數據庫方式實現。
​

總結 這兩種方式都是依賴數據庫的一張表，一種是通過表中的記錄的存在情況確定當前是否有鎖存在，另外一種是通過數據庫的排他鎖來實現分布式鎖。
優點: 直接借助數據庫，容易理解。
缺點: 會有各種各樣的問題，在解決問題的過程中會使整個⽅案變得越來越復雜。 操作數據庫需要一定的開銷，性能問題也需要考慮。
​

Redis實現分布式鎖

redis實現分布式鎖在電商開發中是使用的較為成熟和普遍的一種方式，利用redis本身特性及鎖特性。如高性能(加、解鎖時高性能)，可以使用阻塞鎖與非阻塞鎖。不能出現死鎖。通過搭建redis集群高可用性(不能出現節點 down 掉后加鎖失敗)。
嘗試寫偽代碼增加理解，我們先看這種方式的分布式鎖如何搶占。

    /**
     * @param key 鎖的key
     * @param lockValue 鎖的value
     * @param timeout 允許獲取鎖的時間，超過該時間就返回false
     * @param expire key的緩存時間，也即一個線程⼀次持有鎖的時間，
     * @param sleepTime 獲取鎖的線程循環嘗試獲取鎖的間隔時間
     * @return
     */
    public boolean tryLock(String key, String lockValue, Integer timeout, Integer
            expire, Integer sleepTime) {
        int st = (sleepTime == null) ? DEFAULT_TIME : sleepTime; //允許獲取鎖的時間，默認30秒
        int expiredNx = 30;
        final long start = System.currentTimeMillis();
        if (timeout > expiredNx) {
            timeout = expiredNx;
        }
        final long end = start + timeout * 1000; // 默認返回失敗
        boolean res ;
        //如果嘗試獲取鎖的時間超過了了允許時間，則直接返回
        while (!(res = this.lock(key, lockValue, expire))) { 
            if (System.currentTimeMillis() > end) {
                break;
            }
            try {
            // 線程sleep，避免過度請求Redis，該值可以調整 Thread.sleep(st);
            } catch (InterruptedException e) {
​
            }
        }
        return res;
    }

上⾯的討論中我們有一個⾮常重要的假設:Redis是單點的。如果Redis是集群模式，我們考慮如下場景:
客戶端1和客戶端2同時持有了同一個資源的鎖，鎖不再具有安全性。根本原因是Redis集群不是強⼀致性的。
那么怎么保證強⼀致性呢—Redlock算法
假設客戶端1從Master獲取了鎖。 這時候Master宕機了，存儲鎖的key還沒有來得及同步到Slave上。 Slave升級為Master。 客戶端2從新的Master獲取到了對應同一個資源的鎖。
redLock實現步驟:

1. 客戶端獲取當前時間，以毫秒為單位。客戶端嘗試獲取N個節點的鎖，(每個節點獲取鎖的⽅式和前面說的緩存鎖⼀樣)，N個節點以相同的 key和value獲取鎖。客戶端需要設置接⼝訪問超時，接⼝超時時間需要遠小於鎖超時時間，⽐如鎖⾃動釋放的時間是10s，那么接口超時⼤概設置5-50ms。這樣可以在有redis節點宕機后，訪問該節點時能盡快超時，而減⼩鎖的正常使⽤。
2. 客戶端統計計算在獲得鎖的時候花費了多少時間，當前時間減去在獲取的時間，只有客戶端 獲得了超過3個節點的鎖，⽽且獲取鎖的時間⼩於鎖的超時時間，客戶端才獲得了了分布式鎖。
3. 客戶端獲取鎖的時間為設置的鎖超時時間減去步驟三計算出的獲取鎖花費時間。
4. 如果客戶端獲取鎖失敗了，客戶端會依次刪除所有的鎖。 使⽤用Redlock算法，可以保證在掛掉最多2個節點的時候，分布式鎖服務仍然能⼯工作，這相比之前的數據庫鎖和緩存鎖⼤大提高了可用性，由於redis的高效性能，分布式緩存鎖性能並不比數據庫鎖差。
   但是這種辦法就天衣無縫嗎？缺點在哪里？

• 招架不住 Full GC 帶來的鎖超時問題，Redlock僅僅能相對提⾼可靠性。
  假設客戶端1在獲得鎖之后發生了很長時間的GC pause，在此期間，它獲得的鎖過期了，⽽客戶端2獲得了鎖。當客戶端1從GC pause中恢復過來的時候，它不知道⾃己持有的鎖已經過期了，它依然發起了寫數據請求，⽽這時鎖實際上被客戶端2持有，因此兩個客戶端的寫請求就有可能沖突(鎖的互斥作⽤失效了)。
• 由於必須獲取到5個節點中的3個以上，所以可能出現獲取鎖沖突，即大家都獲得了1-2把鎖，結果誰也不能獲取到鎖，這個問題，redis作者借鑒了了raft算法的精髓，通過沖突后在隨機時間開始，可以大大降低沖突時間，但是這問題並不能很好的避免，特別是在第⼀次獲取鎖的時候，所以獲取鎖的時間成本增加了了。如果5個節點有2個宕機，此時鎖的可用性會極大降低，⾸先必須等待這兩個宕機節點的結果超時才能返回，另外只有3個節點，客戶端必須獲取到這全部3個節點的鎖才能擁有鎖，難度也加⼤了。如果出現網絡分區，那么可能出現客戶端永遠也⽆法獲取鎖的情況。

優點:性能好
缺點:⽆法保證強⼀致性 (即能接受部分數據丟失)

Zookeeper實現分布式鎖

原理
多個進程內同一時間都有線程在執行方法m，那么鎖就一把，你獲得了鎖得以執行，我就得被阻塞，那你執行完了怎么來喚醒我呢？因為你並不知道我被阻塞了，你也就不能通知我" 嗨，小橘，我用完了，你用吧 "。你能做的只有用的時候設置鎖標志，用完了再取消你設置的標志。我就必須在阻塞的時候隔一段時間主動去看看，但這樣總歸是有點麻煩的，最好有人來通知我可以執行了。
而zookeeper對於自身節點的兩大特性解決了這個問題

• 監聽者提供事件通知功能
• znode節點的不可重復特性
  ​
  節點是什么？
  節點是zookeeper中數據存儲的基礎結構，zk中萬物皆節點，就好比java中萬物皆對象是一樣的。zk的數據模型就是基於好多個節點的樹結構，但zk規定每個節點的引用規則是路徑引用。每個節點中包含子節點引用、存儲數據、訪問權限以及節點元數據等四部分。

zk中節點有類型區分嗎？
有。zk中提供了四種類型的節點，各種類型節點及其區別如下：
​
持久節點（PERSISTENT）：節點創建后，就一直存在，直到有刪除操作來主動清除這個節點
持久順序節點（PERSISTENT_SEQUENTIAL）：保留持久節點的特性，額外的特性是，每個節點會為其第一層子節點維護一個順序，記錄每個子節點創建的先后順序，ZK會自動為給定節點名加上一個數字后綴（自增的），作為新的節點名。
臨時節點（EPHEMERAL）：和持久節點不同的是，臨時節點的生命周期和客戶端會話綁定，當然也可以主動刪除。
臨時順序節點（EPHEMERAL_SEQUENTIAL）：保留臨時節點的特性，額外的特性如持久順序節點的額外特性。
​
如何操作節點？
節點的增刪改查分別是create\delete\setData\getData，exists判斷節點是否存在，getChildren獲取所有子節點的引用。
​
上面提到了節點的監聽者，我們可以在對zk的節點進行查詢操作時，設置當前線程是否監聽所查詢的節點。getData、getChildren、exists都屬於對節點的查詢操作，這些方法都有一個boolean類型的watch參數，用來設置是否監聽該節點。一旦某個線程監聽了某個節點，那么這個節點發生的creat（在該節點下新建子節點）、setData、delete（刪除節點本身或是刪除其某個子節點）都會觸發zk去通知監聽該節點的線程。但需要注意的是，線程對節點設置的監聽是一次性的，也就是說zk通知監聽線程后需要改線程再次設置監聽節點，否則該節點再次的修改zk不會再次通知。

實現

• 方案一：使用節點中的存儲數據區域，zk中節點存儲數據的大小不能超過1M，但是只是存放一個標識是足夠的。線程獲得鎖時，先檢查該標識是否是無鎖標識，若是可修改為占用標識，使用完再恢復為無鎖標識。
  ​
• 方案二：使用子節點，每當有線程來請求鎖的時候，便在鎖的節點下創建一個子節點，子節點類型必須維護一個順序，對子節點的自增序號進行排序，默認總是最小的子節點對應的線程獲得鎖，釋放鎖時刪除對應子節點便可。
  ​
  兩種方案其實都是可行的，但是使用鎖的時候一定要去規避死鎖。方案一看上去是沒問題的，用的時候設置標識，用完清除標識，但是要是持有鎖的線程發生了意外，釋放鎖的代碼無法執行，鎖就無法釋放，其他線程就會一直等待鎖，相關同步代碼便無法執行。方案二也存在這個問題，但方案二可以利用zk的臨時順序節點來解決這個問題，只要線程發生了異常導致程序中斷，就會丟失與zk的連接，zk檢測到該鏈接斷開，就會自動刪除該鏈接創建的臨時節點，這樣就可以達到即使占用鎖的線程程序發生意外，也能保證鎖正常釋放的目的。
  那要是zk掛了怎么辦？sad，zk要是掛了就沒轍了，因為線程都無法鏈接到zk，更何談獲取鎖執行同步代碼呢。不過，一般部署的時候，為了保證zk的高可用，都會使用多個zk部署為集群，集群內部一主多從，主zk一旦掛掉，會立刻通過選舉機制有新的主zk補上。zk集群掛了怎么辦？不好意思，除非所有zk同時掛掉，zk集群才會掛，概率超級小。

    /**
     * 嘗試加鎖
     * @return
     */
    public boolean tryLock() {
        // 創建臨時順序節點
        if (this.currentPath == null) {
            // 在lockPath節點下面創建臨時順序節點
            currentPath = this.client.createEphemeralSequential(LockPath + "/", "orangecsong");
        }
        // 獲得所有的子節點
        List<String> children = this.client.getChildren(LockPath);
​
        // 排序list
        Collections.sort(children);
​
        // 判斷當前節點是否是最小的,如果是最小的節點,則表明此這個client可以獲取鎖
        if (currentPath.equals(LockPath + "/" + children.get(0))) {
            return true;
        } else {
            // 如果不是當前最小的sequence,取到前一個臨時節點
            // 1.單獨獲取臨時節點的順序號
            // 2.查找這個順序號在children中的下標
            // 3.存儲前一個節點的完整路徑
            int curIndex = children.indexOf(currentPath.substring(LockPath.length() + 1));
            beforePath = LockPath + "/" + children.get(curIndex - 1);
        }
        return false;
    }
​
    /**
     * 等待鎖
     */
    private void waitForLock() {
        // cdl對象主要是讓線程等待
        CountDownLatch cdl = new CountDownLatch(1);
        // 注冊watcher監聽器
        IZkDataListener listener = new IZkDataListener() {
            @Override
            public void handleDataDeleted(String dataPath) throws Exception {
                System.out.println("監聽到前一個節點被刪除了");
                cdl.countDown();
            }
​
            @Override
            public void handleDataChange(String dataPath, Object data) throws Exception {
            }
        };
​
        // 監聽前一個臨時節點
        client.subscribeDataChanges(this.beforePath, listener);
​
        // 前一個節點還存在,則阻塞自己
        if (this.client.exists(this.beforePath)) {
            try {
                // 直至前一個節點釋放鎖,才會繼續往下執行
                cdl.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
​
        // 醒來后,表明前一個臨時節點已經被刪除,此時客戶端可以獲取鎖 && 取消watcher監聽
        client.unsubscribeDataChanges(this.beforePath, listener);
    }

優點:⾼可用性，數據強一致性。多進程共享、可以存儲鎖信息、有主動通知的機制。
缺點:沒有原⽣⽀持鎖操作，需借助 client 端實現鎖操作，即加⼀次鎖可能會有多次的網絡請求;臨時節點，若在網絡抖動的情況即會導致鎖對應的節點被⽴即釋放，有一定概率會產⽣並發的情況。