集群多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 端實作鎖操作，即加?次鎖可能會有多次的網路請求;臨時節點，若在網路抖動的情況即會導致鎖對應的節點被?即釋放，有一定概率會產?并發的情況，

標籤：Java

上一篇：虛擬機位元組碼指令表

下一篇：python-檔案