redis分散式鎖的問題和解決

分散式鎖

在分散式環境中，為了保證業務資料的正常訪問，防止出現重複請求的問題，會使用分散式鎖來阻攔後續請求。我們先寫一段有問題的業務程式碼：

  public void doSomething(String userId){
        User user=getUser(userId);
        if(user==null){
            user.setUserName("xxxxx");
            user.setUserId(userId);
            insert(user);
            return;
        }
        update(user);
    }

上面的程式碼很簡單，查詢db中有沒有對應的user資料，如果有的話，執行更新操作，如果沒有則插入。

我們知道，上面的程式碼是執行緒不安全的，在多執行緒的環境中，就會出現問題。為了能夠保證資料的正確性，在單機環境下，我們可以使用synchronized的方法，來保證執行緒安全，具體修改：

  public synchronized void doSomething(String userId){
        User user=getUser(userId);
        if(user==null){
            user.setUserName("xxxxx");
            user.setUserId(userId);
            insert(user);
            return;
        }
        update(user);
    }

在單機器的環境下，能夠解決執行緒安全的問題，那在分散式環境下呢？ 這個時候需要用到分散式鎖.

分散式鎖需要藉助其他元件來實現，常用的有redis和zookeeper。下面我們就用redis的實現，來說明下問題，分散式鎖具體的實現方法如下

    public  void doSomething(String userId){
        String lock=RedisUtils.get("xxxx"+userId);
        if(StringUtils.isNotEmpty(lock)){//說明當前userId已經被鎖定
            return;
        }
        RedisUtils.set("xxxx"+userId,userId,1000);//鎖定10s
        User user=getUser(userId);
        if(user==null){
            insert(user);
            RedisUtils.delete("xxxx"+userId);
            return;
        }
        update(user);
        RedisUtils.delete("xxxx"+userId);
        
    }

上面的程式碼解決了在分散式環境中的併發的問題。但同樣需要考慮一個問題，如果insert操作和update操作異常了，分散式鎖不會釋放，後續的請求還會被攔截。

所以我們再優化，增加對異常的捕獲。

 public  void doSomething(String userId){
        try {
                String lock=RedisUtils.get("xxxx"+userId);
                if(StringUtils.isNotEmpty(lock)){//說明當前userId已經被鎖定
                    return;
                }
                RedisUtils.set("xxxx"+userId,userId,1000);//鎖定1s
                User user=getUser(userId);
                if(user==null){
                    insert(user);
                    return;
                }
                update(user);
        }
        catch(Exception ex){

        }
        finally{
            RedisUtils.delete("xxxx"+userId);
        }
    }

 現在即使是程式異常了，鎖會自動釋放。但redis的get和set也會存在併發問題，我們再繼續優化，使用redis中的setnx方法

    public  void doSomething(String userId){
        try {
                boolean lock=RedisUtils.setnx("xxxx"+userId,userId,1000);//鎖定1s
                if(!lock){//說明當前userId已經被鎖定
                    return;
                }
                User user=getUser(userId);
                if(user==null){
                    insert(user);
                    return;
                }
                update(user);
        }
        catch(Exception ex){

        }
        finally{
            RedisUtils.delete("xxxx"+userId);
        }
    }

 

 

上面的程式碼好像沒有什麼問題了，但也存在很大的隱患。 我們分析下，假設第一個請求過來，執行鎖定成功，程式開始執行，但是insert和update操作阻塞了1s，第二個請求過來，鎖的快取已經過期，第二個執行鎖定成功，這個時候第一個請求完成了鎖被釋放，第二個請求的鎖就被第一次請求釋放了，第三次的請求就會造成執行緒不安全問題。

怎麼再去優化呢？問題主要是出現在第一次請求誤刪鎖的問題，所以我們在移除鎖的時候要判斷能否移除。

思路：我們在鎖定的時候，value使用當前的時間戳，刪除時判斷是否過期如果不過期就不要刪除，具體程式碼如下：

public  void doSomething(String userId){
        try {
                boolean lock=RedisUtils.setnx("xxxx"+userId,LocalDateTime.now(),1000);//鎖定10s
                if(!lock){//說明當前userId已經被鎖定
                    return;
                }
                User user=getUser(userId);
                if(user==null){
                    insert(user);
                    return;
                }
                update(user);
        }
        catch(Exception ex){

        }
        finally{
            LocalDateTime lockTIme=    RedisUtils.get("xxxx"+userId);
            if(lockTIme.compare(LocalDateTime.now())<0){
                //說明已經過期，可以刪除key
                RedisUtils.delete("xxxx"+userId);
            }
        }
    }

 

 

 這樣即使出現阻塞，第二次的時間戳覆蓋了第一次的鎖定，這樣即使第一次完成了，也不會釋放鎖。