当前位置：首页 > article >正文

Rides实现分布式锁，保障数据一致性,Redisson分布式事务处理

article 2024/11/15 7:50:31

分布式环境下分布式锁有三种方式：

基于数据库分布式锁

基于Redis分布式锁

基于zk分布式锁

本帖只介绍Redis分布式锁

为什么需要用到分布式锁？

在单机环境下一个服务中多个线程对同一个事物或数据资源进行操作时，可以通过添加加锁方式（synchronized和lock）来解决数据一致性的问题。

但是如果出现多个服务的情况下，这时候我们在通过synchronized和lock的方式来加锁会出现问题，因为多个服务的内存不是共享的，加锁只能添加到当前服务的进程和线程。

所以出现了分布式锁，用来解决同一时间分布式系统之间对同一事物或数据资源操作的问题，从而保证数据的一致性。

基于Redis的分布式锁

基于string类型集合中的setnx（原子性的）方法命令来做的分布式锁。

简单加锁

Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", "1");
        if (lock) {
            // 加锁成功
            // 执行业务
            // 释放锁
        }else {
            // 加锁失败。。重试（可以通过自旋方式重试）

        }

存在的问题：

如果业务代码异常，在执行过程中宕机。没有执行删除锁逻辑，这样就会造成死锁，导致锁无法被释放，其他服务线程无法继续执行逻辑。

解决：

设置锁的过期时间，保障如果没有正常删除可以自动删除锁。

解决死锁加锁

重点：要保证加锁和设置过期时间的原子性操作，以避免加锁后宕机造成死锁。

// redis占分布式锁并设置过期时间
        Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", "1",100,TimeUnit.MILLISECONDS);
        if (lock) {
            // 加锁成功
            // 执行业务
            // 释放锁
        }else {
            // 加锁失败。。重试（可以通过自旋方式重试）

        }

存在问题：

1.业务超时问题（业务处理时间大于锁的过期时间）。

2. 业务超时，导致在执行删锁操作时，其实自己的锁早过期了，此时的锁正被其他人所持有，这时候会删除掉别人的锁。

解决：删除锁必须保证原子性。使用redis——Lua脚本完成。

Lua脚本加锁

String uuid = UUID.randomUUID().toString();
        Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", "1",100,TimeUnit.MILLISECONDS);
        if (lock) {
            // 加锁成功
            try {
                // 执行业务
            }finally {
                // 释放锁,Lua脚本删除锁，保证删除原子性
                String script = "if redis.call('get', KEYS[1]) == tonumber(ARGV[1]) then return redis.call('del', KEYS[1]) else return 0 end";
                stringRedisTemplate.execute(new DefaultRedisScript<Long>(script,Long.class), Arrays.asList("locl"),uuid);
            }
        }else {
            // 加锁失败。。重试（可以通过自旋方式重试）

        }

业务续期问题：业务执行时间过长，在业务没有执行完却自动过期删除了。解决的最简单办法就是设置一个比较长的过期时间。

redis分布式锁核心两处：1.加锁原子性，2解锁原子性。

那么如何实现我们分布式的各种锁呢，因为分布式不只是我们简单的上述一个简单锁，如果我们也想用读写锁、闭锁、信号量等需要怎么实现。基于java还有 redis分布式锁有更专业的框架Redisson

Redisson

Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务。其中包括(BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, Bloom filter, Remote service, Spring cache, Executor service, Live Object service, Scheduler service) Redisson提供了使用Redis的最简单和最便捷的方法。Redisson的宗旨是促进使用者对Redis的关注分离（Separation of Concern），从而让使用者能够将精力更集中地放在处理业务逻辑上。

Redisson实现分布式锁

1.Redisson实现分布式锁

        // 获取锁
        RLock lock = redissonClient.getLock("lock");
        try {
            // 加锁
            lock.lock();
            // 处理业务

        }catch (Exception e){
            e.printStackTrace();


        }finally {
            // 释放锁
            lock.unlock();
        }

重点：

1.Redisson加锁自动有过期时间默认30s，Redisson看门狗如果业务没有执行完，会自动进行锁的续期（30s），防止程序还没执行结束，锁自动删除。

2.如果业务执行完成没有手动释放锁，锁的过期时间到了也会自动释放锁。

2.Redisson分布式锁定时过期

// 10秒钟以后自动解锁
// 无需调用unlock方法手动解锁
fairLock.lock(10, TimeUnit.SECONDS);

重点：

如果设置了锁的超时时间，默认超时就是我们指定的时间，不会自动续期。

如果我们未指定锁的超时时间，就会使用30s（看门狗的默认时间）。

看门狗的原理：只要未指定超时时间站锁成功，就会启动一个定时任务（看门狗，重新给锁设置过期时间，新的过期时间就是看门狗的默认时间），看门狗每隔10秒（看门狗默认时间的/3）都会再次续期30s。

3.分布式锁-尝试锁

// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);
if (res) {
   try {
     ...
   } finally {
       lock.unlock();
   }
}

尝试锁会在设定的尝试时间内等待，一旦超过这个等待时间就自动结束等待。

公平锁

公平锁相对上述来说只不过是换了一个方法，与之前的使用方法是一样的。

基于Redis的Redisson分布式可重入公平锁也是实现了java.util.concurrent.locks.Lock接口的一种RLock对象。同时还提供了异步（Async）、反射式（Reactive）和RxJava2标准的接口。它保证了当多个Redisson客户端线程同时请求加锁时，优先分配给先发出请求的线程。所有请求线程会在一个队列中排队，当某个线程出现宕机时，Redisson会等待5秒后继续下一个线程，也就是说如果前面有5个线程都处于等待状态，那么后面的线程会等待至少25秒。

RLock fairLock = redisson.getFairLock("anyLock");
// 最常见的使用方法
fairLock.lock();

读写锁

1.读写锁

基于Redis的Redisson分布式可重入读写锁RReadWriteLock。

分布式可重入读写锁允许同时有多个读锁和一个写锁处于加锁状态。

RReadWriteLock rwlock = redisson.getReadWriteLock("anyRWLock");
// 读锁
rwlock.readLock().lock();
// 写锁
rwlock.writeLock().lock();

重点：

锁名一样就是同一把读写锁，读加读锁，修改是加写锁。如果别人正在修改数据，我们还想读取到最新数据，那么这时候就需要等待写锁释放，读取数据才能进行。

如果都是并发读，互相并不影响。只要写锁存在，读锁就要等待。

如果负责储存这个分布式锁的Redis节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定。

2.读写锁设置过期时间

Redisson还通过加锁的方法提供了leaseTime的参数来指定加锁的时间。超过这个时间后锁便自动解开了。

// 10秒钟以后自动解锁
// 无需调用unlock方法手动解锁
rwlock.readLock().lock(10, TimeUnit.SECONDS);
// 或
rwlock.writeLock().lock(10, TimeUnit.SECONDS);

// 尝试加锁，最多等待100秒，上锁以后10秒自动解锁
boolean res = rwlock.readLock().tryLock(100, 10, TimeUnit.SECONDS);
// 或
boolean res = rwlock.writeLock().tryLock(100, 10, TimeUnit.SECONDS);
...
lock.unlock();

信号量

基于Redis的Redisson的分布式信号量，提供了异步（Async）、反射式（Reactive）和RxJava2标准的接口。

RSemaphore semaphore = redisson.getSemaphore("semaphore");
// 获取一个信号
semaphore.acquire();

//或
semaphore.acquireAsync();
semaphore.acquire(23);
semaphore.tryAcquire();
//或
semaphore.tryAcquireAsync();
semaphore.tryAcquire(23, TimeUnit.SECONDS);
//或
semaphore.tryAcquireAsync(23, TimeUnit.SECONDS);
semaphore.release(10);
semaphore.release();
// 释放一个信号
semaphore.releaseAsync();

信号量可用作限流，假如我们的服务器只能支撑1w个并发，这是我们可是使用信号量来处理。

闭锁

应用场景设置数量，当数量全部消耗完成闭锁。

RCountDownLatch latch = redisson.getCountDownLatch("anyCountDownLatch");
// 设置数量
latch.trySetCount(3);
// 等待数量消耗完成，然后闭锁
latch.await();

------------------------
// 在其他线程或其他JVM里
RCountDownLatch latch = redisson.getCountDownLatch("anyCountDownLatch");
// 计数减1
latch.countDown();

查看全文

http://www.kler.cn/a/289946.html