快捷導(dǎo)航

MySql實現(xiàn)分布式鎖詳解

更新時間：2024年11月03日 09:42:31 作者：我是小趴菜

這篇文章主要為大家詳細(xì)介紹了如何使用本地MySql實現(xiàn)一把分布式鎖,以及Mysql實現(xiàn)分布式鎖的原理是怎么樣的,有需要的小伙伴可以了解下

1：基于行鎖實現(xiàn)分布式鎖

實現(xiàn)原理

首先我們的表lock要提前存好相對應(yīng)的lockName，這時候多個客戶端來執(zhí)行

  select lock_name from lock where lock_name = #{lockName} for update

由于第一個客戶端來執(zhí)行這條sql語句，給這行記錄加了行鎖，在這個客戶端沒有提交事務(wù)之前，其它客戶端就會被阻塞住。所以這時候就只能有一個客戶端去執(zhí)行我們自己的業(yè)務(wù)了，其它客戶端就只能阻塞等待，那么這個過程就是加鎖

那么釋放鎖該怎么操作呢？

其實釋放鎖就很簡單了，也就是將獲取到鎖的這個客戶端的事務(wù)提交，這樣其它客戶端就可以來獲取到這把行鎖了，所以這時候就需要我們手動的提交事務(wù)了

代碼實現(xiàn)

首先就是編寫我們的加鎖SQL語句了

@Select("select lock_name from lock where lock_name = #{lockName} for update")
List<String> queryLockNameForUpdate(@Param("lockName") String lockName);

然后我們需要實現(xiàn)我們的加鎖和解鎖

public class MySqlDistributeLock {

    //加鎖的KEY，也就是我們提前存到表lock的值
    private String lockName;

    //手動提交事務(wù)需要的事務(wù)管理器,由外部傳入
    private DataSourceTransactionManager dataSourceTransactionManager;

    //自定義編寫的mybatis的mapper文件
    private MySqlLockMapper mySqlLockMapper;

    private TransactionStatus status;

    public MySqlDistributeLock(String lockName,DataSourceTransactionManager dataSourceTransactionManager,MySqlLockMapper mySqlLockMapper) {
        this.lockName = lockName;
        this.dataSourceTransactionManager = dataSourceTransactionManager;
        this.mySqlLockMapper = mySqlLockMapper;
    }


    
    public void lock() {
        TransactionDefinition transactionDefinition = new DefaultTransactionDefinition();
        status = dataSourceTransactionManager.getTransaction(transactionDefinition);
        while (true) {
            try{
                mySqlLockMapper.queryLockNameForUpdate(this.lockName);
                //如果加鎖成功，就退出該循環(huán)
                break;
            }catch (Exception e) {
                //說明拋出異常了,讓線程重試
                try {
                    //讓線程休眠一會
                    Thread.sleep(100);
                } catch (InterruptedException ignored) { }
            }
        }
    }


    public void unLock() {
        //手動提交事務(wù),也就是釋放鎖
        dataSourceTransactionManager.commit(this.status);
    }
}

最后看下業(yè)務(wù)方如何使用

@Service
public class LockService {


    @Resource
    private DataSourceTransactionManager dataSourceTransactionManager;

    @Resource
    private MySqlDistributeLock.MySqlLockMapper mySqlLockMapper;



    public String deductStockMysqlLock(String productId,Integer count) {
        MySqlDistributeLock lock = null;
        try{
            lock = new MySqlDistributeLock(productId,dataSourceTransactionManager,mySqlLockMapper);
            //加鎖
            lock.lock();

            //加鎖成功，開始執(zhí)行我們自己的業(yè)務(wù)邏輯
        }finally {
            if(lock != null) {
                lock.unLock();
            }
        }
        return "success";
    }
}

2：基于唯一索引實現(xiàn)分布式鎖

實現(xiàn)原理

首先我們的lock表要給lock_name字段建立一個唯一索引，這時候有多個客戶端來加鎖，本質(zhì)上也就是添加一條記錄，只不過lockName的值都是一樣的

這時候客戶端A成功的把lockName保存到lock表中了，那么其它客戶端要保存這個lockName的時候(也就是執(zhí)行加鎖),由于唯一索引的緣故，就會插入失敗。也就保證了同一個時間只能有一個客戶端保存成功，也就是加鎖成功了

那么如何釋放鎖呢？

在這個客戶端業(yè)務(wù)執(zhí)行完之后，手動的把這條記錄刪除掉，那么其它客戶端就可以來繼續(xù)加鎖了

代碼實現(xiàn)

首先我們在mapper文件中編寫加鎖和解鎖的SQL，這里為什么還要保存?zhèn)€uuid，后續(xù)會講到（主要是防止鎖被誤刪）

//加鎖語句
@Insert("insert into record_lock (lock_name, uuid) values (#{lockName}, #{uuid})")
Integer insert(@Param("lockName") String lockName, @Param("uuid") String uuid);

//解鎖語句
@Delete("delete from record_lock where lock_name = #{lockName} and uuid = #{uuid}")
Integer delete(@Param("lockName") String lockName,  @Param("uuid") String uuid);

然后我們需要實現(xiàn)我們的加鎖和解鎖

public class MySqlDistributeLock {


    private String lockName;

    //自定義編寫的mybatis的mapper文件
    private MySqlLockMapper mySqlLockMapper;

    private String uuid;


    public MySqlDistributeLock(String lockName,MySqlLockMapper mySqlLockMapper,String uuid) {
        this.lockName = lockName;
        this.mySqlLockMapper = mySqlLockMapper;
        this.uuid = uuid;
    }


    
    public void lock() {
        while (true) {
              try{
                  int result = mySqlLockMapper.insert(this.lockName, this.uuid);
                  if(result > 0) {
                      //代表加鎖成功
                      break;
                  }
              } catch (Exception e) {
              }

            //唯一索引加鎖失敗
            try {
                Thread.sleep(100);
            } catch (InterruptedException interruptedException) {
                throw new RuntimeException();
            }
        }
    }


    public void unLock() {
        mySqlLockMapper.delete(this.lockName,this.uuid);
    }
}

最后看下業(yè)務(wù)方如何使用

@Service
public class LockService {
    
    @Resource
    private MySqlDistributeLock.MySqlLockMapper mySqlLockMapper;



    public String deductStockMysqlLock(String productId,Integer count) {
        MySqlDistributeLock lock = null;
        try{
            lock = new MySqlDistributeLock(productId, mySqlLockMapper,UUID.randomUUID().toString());
            //加鎖
            lock.lock();

            //加鎖成功，開始執(zhí)行我們自己的業(yè)務(wù)邏輯
        }finally {
            if(lock != null) {
                lock.unLock();
            }
        }
        return "success";
    }
}

基于唯一索引實現(xiàn)的分布式鎖有沒有什么問題呢？？

死鎖問題

我們試想一下，如果客戶端A來加鎖成功了，業(yè)務(wù)也執(zhí)行完了，但是這時候釋放鎖的時候，也就是執(zhí)行刪除語句的時候因為一些原因?qū)е聞h除失敗了，那么這條記錄一直存在，后續(xù)的線程就沒辦法再獲取到鎖了，這就是所謂的死鎖

所以這時候我們還需要另外一個服務(wù)來定時掃描這些記錄，如果這個記錄超過了10分鐘，或者20分鐘還沒有被刪除掉，那么大概率是釋放鎖的時候失敗了，所以需要再次刪除這條記錄

鎖誤刪

為什么鎖會誤刪呢？為了防止死鎖，我們會有一個單獨的定時任務(wù)來掃描，假設(shè)我們判斷一把鎖超過10分鐘就認(rèn)為是釋放鎖失敗了，這時候定時任務(wù)就會把這條記錄刪除掉，但是這時候就會有問題了，舉個例子

客戶端A首先獲取到鎖了，然后開始執(zhí)行業(yè)務(wù)，但是因為業(yè)務(wù)比較復(fù)雜，執(zhí)行完業(yè)務(wù)可能需要15分鐘，這時候到第10分鐘的時候，定時任務(wù)就會把這條記錄給刪除掉了

這時候因為記錄沒有了，客戶端B來獲取鎖是能成功獲取到的，所以這時候這把鎖的持有者應(yīng)該是客戶端B的

到第15分鐘的時候，客戶端A業(yè)務(wù)執(zhí)行完了，就是執(zhí)行釋放鎖的邏輯，那么客戶端A就會把這條記錄給刪除掉了，也就導(dǎo)致客戶端A把客戶端B的鎖給釋放掉了

所以在開頭的時候，我們加鎖除了要保存lockName,還要保存一個uuid,在釋放鎖的時候，判斷一下uuid是否相等，如果不相等，那就不能刪除這條記錄了，因為這時候這把鎖已經(jīng)不是當(dāng)前客戶端持有的了

鎖續(xù)期

大家可以想一下，分布式鎖的主要目的就是同一個時間點只能有一個線程去執(zhí)行業(yè)務(wù)，但是在上面我們可以看到，即使加了uuid來保證了鎖誤刪，但是在同一個時間點可能是有多個線程在一起執(zhí)行業(yè)務(wù)的，為了避免這種情況，就需要保證一個客戶端在沒有執(zhí)行完業(yè)務(wù)以前，是不允許其它客戶端執(zhí)行業(yè)務(wù)的

但是定時任務(wù)判斷的時間我們沒辦法預(yù)估，可能業(yè)務(wù)需要10分鐘，也有可能是20分鐘，我們沒辦法準(zhǔn)確預(yù)估這個時間

所以我們在一個客戶端加鎖成功之后，可以起一個額外的線程，時時的更新加鎖的時間，這就類似Redisson的看門狗機(jī)制了，那么如何去做呢？？