快捷導(dǎo)航

SpringBoot integration實現(xiàn)分布式鎖的示例詳解

更新時間：2023年12月11日 08:07:35 作者：zooooooooy

常規(guī)項目都是采用Redission來實現(xiàn)分布式鎖,進(jìn)行分布式系統(tǒng)中資源競爭加鎖操作,偶然發(fā)現(xiàn)SpringBoot中的integration也實現(xiàn)多種載體的分布式鎖控制,下面我們就來看看具體實現(xiàn)方法吧

代碼集成

引入

// 分布式鎖
implementation 'org.springframework.boot:spring-boot-starter-integration'
implementation('org.springframework.integration:spring-integration-redis')

采用最常見的redis來作為分布式鎖的底層載體。

鎖注冊

在@Configuration配置類中，添加分布式鎖注冊信息。

@Bean
open fun redisLockRegistry(redisConnectionFactory: RedisConnectionFactory): RedisLockRegistry {

    return RedisLockRegistry(redisConnectionFactory, "fcDistroLock", 20000L)
}

有兩個核心參數(shù)，第一個指定的是分布式鎖的前綴，第二個是指定分布式鎖的過期時間。過期時間建議不要指定到過長，防止拖慢整體的業(yè)務(wù)響應(yīng)速度。

加鎖

在使用之前需要知道加鎖的三個核心方法。

lock	直接加鎖，一直等待
tryLock(無參數(shù)）	嘗試加鎖，未獲取到鎖，直接返回失敗
tryLock(long time, TimeUnit unit)	嘗試加鎖，等待一定時間后未獲取到鎖，直接返回失敗

建議使用帶參數(shù)的嘗試加鎖，設(shè)置一個合適的超時時間。建議使用模式如下

Lock lock = ...;
if (lock.tryLock(time)) {
  try {
    // manipulate protected state
  } finally {
    lock.unlock();
  }
} else {
  // perform alternative actions
}}

有一個點需要注意，當(dāng)加鎖失敗時，需要考慮補(bǔ)償機(jī)制。例如用戶余額扣減失敗，需要重新進(jìn)行推送；或者加鎖失敗，拋出異?；貪L本地事務(wù)等。

使用上非常簡單。

細(xì)粒度加鎖

可以通過上圖可以看到，我們加鎖的對象是用戶id，并不是所有用戶。代表不同用戶之間操作是不受分布式事務(wù)限制。這里同步會衍生另外一個問題，如果用戶id特別多，就會占用非常多的資源。這里就需要定時手動清除加鎖對象，或者加鎖成功后直接清除。個人建議使用定時清除，有助于減少對象的創(chuàng)建，提高系統(tǒng)吞吐量。

@Scheduled(cron = "0 0 0/1 * * ?")
fun scheduleRemoveRedisLock() {

    redisLockRegistry.expireUnusedOlderThan(1000 * 60 * 60)
}

RedisLockRegistry其實已經(jīng)提供清除的方法，我們只需要指定清除的有效期即可。項目中指定的是清除1個小時之前的加鎖對象。

核心邏輯

打開tryLock的實現(xiàn)類RedisLock很容易發(fā)現(xiàn)，每個加鎖id都對應(yīng)1個RedisLock，1個RedisLock中包含1個ReentrantLock，用來進(jìn)行本地資源互斥。

public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
   long now = System.currentTimeMillis();
   if (!this.localLock.tryLock(time, unit)) { // 獲取本地互斥鎖
      return false;
   }
   try {
      long expire = now + TimeUnit.MILLISECONDS.convert(time, unit);
      boolean acquired;
      while (!(acquired = obtainLock()) && System.currentTimeMillis() < expire) { //NOSONAR
         Thread.sleep(100); //NOSONAR 防止請求過快，進(jìn)行100Ms的休眠
      }
      if (!acquired) {
         this.localLock.unlock();
      }
      return acquired;
   }
   catch (Exception e) {
      this.localLock.unlock();
      rethrowAsLockException(e);
   }
   return false;
}

兩個條件跳出循環(huán)獲取鎖的過程。

超過等待時間
redis返回是否獲取到鎖

Redis鎖邏輯判斷

private static final String OBTAIN_LOCK_SCRIPT =
      "local lockClientId = redis.call('GET', KEYS[1])\n" +
            "if lockClientId == ARGV[1] then\n" +
            "  redis.call('PEXPIRE', KEYS[1], ARGV[2])\n" +
            "  return true\n" +
            "elseif not lockClientId then\n" +
            "  redis.call('SET', KEYS[1], ARGV[1], 'PX', ARGV[2])\n" +
            "  return true\n" +
            "end\n" +
            "return false";

利用Redis的原子性進(jìn)行鎖資源判斷，通過是否相同應(yīng)用id來支持重入鎖。

整體使用

使用上非常簡單，沒有鎖續(xù)期，沒有讀寫鎖，也沒有考慮重入鎖的計數(shù)問題。功能上還是比Redission差不少，在一些業(yè)務(wù)相對比較簡單的場景可以嘗試使用SpringBoot自帶的分布式鎖。如果需要面對更細(xì)粒度的控制，提高性能，更復(fù)雜的鎖控制，就需要使用到Redission來進(jìn)行分布式鎖的編寫了。

到此這篇關(guān)于SpringBoot integration實現(xiàn)分布式鎖的示例詳解的文章就介紹到這了,更多相關(guān)SpringBoot integration分布式鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: