基于Redis實作分布式鎖-有解無憂

我們知道分布式鎖的特性是排他、避免死鎖、高可用，分布式鎖的實作可以通過資料庫的樂觀鎖(通過版本號)或者悲觀鎖(通過for update)、Redis的setnx()命令、Zookeeper(在某個持久節點添加臨時有序節點，判斷當前節點是否是序列中最小的節點，如果不是則監聽比當前節點還要小的節點，如果是，獲取鎖成功，當被監聽的節點釋放了鎖(也就是被洗掉)，會通知當前節點，然后當前節點再嘗試獲取鎖，如此反復)

redis.png

本篇文章，主要講如何用Redis的形式實作分布式鎖，后續文章會講解熱點KEY讀取，快取穿透和快取雪崩的場景和解決方案、快取更新策略等等知識點，理論知識點較多，

Redis配置

spring:
  redis:
    port: 6379
    database: 0
    host: 127.0.0.1
    password:
    jedis:
      pool:
        max-active: 8
        max-wait: -1ms
        max-idle: 8
        min-idle: 0
    timeout: 5000ms

Jedis工具類

public class JedisConnectionUtil {

    private static JedisPool pool = null;

    static {
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(100);
        pool = new JedisPool(jedisPoolConfig, "127.0.0.1", 6379);
    }

    public static Jedis getJedis(){
        return pool.getResource();
    }
}

分布式鎖分析與編碼

下面進入正文，因為分布式系統之間是不同行程的，單機版的鎖無法滿足要求，所以我們可以借助中間件Redis的setnx()命令實作分布式鎖，setnx()命令只會對不存在的key設值，回傳1代表獲取鎖成功，對存在的key設值，會回傳0代表獲取鎖失敗，這里的value是System.currentTimeMillis() (獲取鎖的時間)+鎖持有的時間，我這里設定鎖持有的時間是200ms，實際業務執行的時間遠比這200ms要多的多，持有鎖的客戶端應該檢查鎖是否過期，保證鎖在釋放之前不會過期，因為客戶端故障的情況可能是很復雜的，比如現在有A，B倆個客戶端，A客戶端獲取了鎖，執行業務中做了騷操作導致阻塞了很久，時間應該遠遠超過200ms，當A客戶端從阻塞狀態下恢復繼續執行業務代碼時，A客戶端持有的鎖由于過期已經被其他客戶端占有，這時候A客戶端執行釋放鎖的操作，那么有可能釋放掉其他客戶端的鎖，

我這里設定的客戶端等待鎖的時間是200ms，這里通過輪詢的方式去讓客戶端獲取鎖，如果客戶端在200ms之內沒有鎖的話，直接回傳false，實際場景要設定合適的客戶端等待鎖的時間，避免消耗CPU資源，

獲取鎖

/**
 * 獲取鎖
 * @param lockName 鎖的名字
 * @param acquireTimeout 或得所的超時時間
 * @param lockTimeout 所本身的超時時間
 * @return
 */
public String acquireLock(String lockName, long acquireTimeout, long lockTimeout){
    // 鎖標識
    String identifler = UUID.randomUUID().toString();
    String lockKey = "lock" + lockName;
    int lockExpire = (int) (lockTimeout / 1000);
    Jedis jedis = null;

    try {
        jedis = JedisConnectionUtil.getJedis();

        long end = System.currentTimeMillis() + acquireTimeout;
        // 獲取鎖的限定時間
        while (System.currentTimeMillis() < end) {
            if (jedis.setnx(lockKey, identifler) == 1) {
                // 設定成功
                // 設定超時時間
                jedis.expire(lockKey, lockExpire);
                // 或得鎖成功
                return identifler;
            }
            if (jedis.ttl(lockKey) == -1) {
                // 如果一直沒有或得鎖設定超時時間
                jedis.expire(lockKey, lockExpire);
            }
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }finally {
        jedis.close();
    }
    return null;
}

所以，我們要加上鎖過期，然后獲取鎖的策略，通過realKey獲取當前的currentValue，currentValue也就是獲取鎖的時間 + 鎖持有的時間，如果currentValue不等于null 且 currentValue 小于當前時間，說明鎖已經過期，這時候如果突然來了C，D兩個客戶端獲取鎖的請求，不就讓C，D兩個客戶端都獲取鎖了嗎，如果防止這種現象發生，我們采用getSet()命令來解決，getSet(key,value)的命令會回傳key對應的value，然后再把key原來的值更新為value，也就是說getSet()回傳的是已過期的時間戳，如果這個已過期的時間戳等于currentValue，說明獲取鎖成功，

釋放鎖

/**
 * 釋放鎖
 * @param lockName 鎖的名字
 * @param identifler 鎖標識
 * @return
 */
public boolean releaseLock(String lockName, String identifler){
    System.out.println(lockName + "釋放鎖" + identifler);
    String lockKey = "lock:" + lockName;
    Jedis jedis = null;
    boolean isrelease = false;
    try {
        jedis = JedisConnectionUtil.getJedis();
        while (true){
            jedis.watch(lockKey);
            // 判斷是否是同一把鎖
            if (identifler.equals(jedis.get(lockKey))){
                Transaction transaction = jedis.multi();
                transaction.del(lockKey);
                if (transaction.exec().isEmpty()){
                    continue;
                }
                isrelease = true;
            }
            // TODO 例外
            jedis.unwatch();
            break;
        }
    }finally {
        jedis.close();
    }
    return isrelease;
}

撰寫測驗類用多執行緒模擬高并發

public class UnitTest extends Thread {

    @Override
    public void run() {
        while (true){
            DistributedLock distributedLock = new DistributedLock();
            String rs = distributedLock.acquireLock("updateOrder", 2000, 5000);
            if (rs != null){
                System.out.println(Thread.currentThread().getName() + "-> 或得鎖" + rs);
                try {
                    Thread.sleep(1000);
                    distributedLock.releaseLock("updateOrder", rs);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                break;
            }
        }
    }

    public static void main(String[] args) {
        UnitTest unitTest = new UnitTest();
        for (int i = 0; i < 10; i++) {
            new Thread(unitTest, "tName:" + i).start();
        }
    }
}

代碼運行結果

tName:0-> 或得鎖a86a2867-a5f9-4b81-8be6-105d50b8a1ab
updateOrder釋放鎖a86a2867-a5f9-4b81-8be6-105d50b8a1ab
tName:1-> 或得鎖bcdeb19c-a47c-4a12-86df-8e5d90b2ecb0
updateOrder釋放鎖bcdeb19c-a47c-4a12-86df-8e5d90b2ecb0
tName:6-> 或得鎖147d9fc8-5e15-4e86-8da6-e029a3e2d92f
updateOrder釋放鎖147d9fc8-5e15-4e86-8da6-e029a3e2d92f
tName:2-> 或得鎖93deb41d-2439-45e7-beb1-2e4ce672e8ca
updateOrder釋放鎖93deb41d-2439-45e7-beb1-2e4ce672e8ca
tName:4-> 或得鎖094f921d-fe9b-46ba-873b-aee2ce974f16
updateOrder釋放鎖094f921d-fe9b-46ba-873b-aee2ce974f16
tName:5-> 或得鎖216e0799-6d22-4ae4-bb83-9efe1e5f80c9
updateOrder釋放鎖216e0799-6d22-4ae4-bb83-9efe1e5f80c9
tName:9-> 或得鎖678e2099-651c-4e23-a648-9fb588ecb42b
updateOrder釋放鎖678e2099-651c-4e23-a648-9fb588ecb42b
tName:7-> 或得鎖f35cdbad-6fde-4f1e-a4c1-321805a39374
updateOrder釋放鎖f35cdbad-6fde-4f1e-a4c1-321805a39374
tName:3-> 或得鎖0913a4a0-805a-48e2-ac5a-c0762b8c4072
updateOrder釋放鎖0913a4a0-805a-48e2-ac5a-c0762b8c4072
tName:8-> 或得鎖a3964a2a-6b9c-4ca3-9ea5-53de854c23ce
updateOrder釋放鎖a3964a2a-6b9c-4ca3-9ea5-53de854c23ce

本文文字部分參考文章:https://www.jianshu.com/p/83224c0f3bb9

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/35515.html

標籤：NoSQL

上一篇：MongoDB Java API操作很全的整理以及共享分片模式下的常見操作整理

下一篇：SQLyog使用期限（治標不治本的，治本的還沒找到）