Java自学资料！docker集群springcloud

本文主要是介绍Java自学资料！docker集群springcloud，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

1.为什么要使用分布式锁

使用分布式锁的目的，无外乎就是保证同一时间只有一个客户端可以对共享资源进行操作。

1.1举一个很长的例子

系统 A 是一个电商系统，目前是一台机器部署，系统中有一个用户下订单的接口，但是用户下订单之前一定要去检查一下库存，确保库存足够了才会给用户下单。由于系统有一定的并发，所以会预先将商品的库存保存在 Redis 中，用户下单的时候会更新 Redis 的库存。此时系统架构如下：

但是这样一来会产生一个问题：假如某个时刻，Redis 里面的某个商品库存为 1。

此时两个请求同时到来，其中一个请求执行到上图的第 3 步，更新数据库的库存为 0，但是第 4 步还没有执行。

而另外一个请求执行到了第 2 步，发现库存还是 1，就继续执行第 3 步。这样的结果，是导致卖出了 2 个商品，然而其实库存只有 1 个。

很明显不对啊！这就是典型的库存超卖问题。此时，我们很容易想到解决方案：用锁把 2、3、4 步锁住，让他们执行完之后，另一个线程才能进来执行第 2 步。

按照上面的图，在执行第 2 步时，使用 Java 提供的 Synchronized 或者 ReentrantLock 来锁住，然后在第 4 步执行完之后才释放锁。

这样一来，2、3、4 这 3 个步骤就被“锁”住了，多个线程之间只能串行化执行。

当整个系统的并发飙升，一台机器扛不住了。现在要增加一台机器，如下图：

增加机器之后，系统变成上图所示，假设此时两个用户的请求同时到来，但是落在了不同的机器上，那么这两个请求是可以同时执行了，还是会出现库存超卖的问题。

因为上图中的两个 A 系统，运行在两个不同的 JVM 里面，他们加的锁只对属于自己 JVM 里面的线程有效，对于其他 JVM 的线程是无效的。

因此，这里的问题是：Java 提供的原生锁机制在多机部署场景下失效了，这是因为两台机器加的锁不是同一个锁（两个锁在不同的 JVM 里面）。

那么，我们只要保证两台机器加的锁是同一个锁，问题不就解决了吗？此时，就该分布式锁隆重登场了。

分布式锁的思路是：在整个系统提供一个全局、唯一的获取锁的“东西”，然后每个系统在需要加锁时，都去问这个“东西”拿到一把锁，这样不同的系统拿到的就可以认为是同一把锁。

至于这个“东西”，可以是 Redis、Zookeeper，也可以是数据库。此时的架构如图：

通过上面的分析，我们知道了库存超卖场景在分布式部署系统的情况下使用 Java 原生的锁机制无法保证线程安全，所以我们需要用到分布式锁的方案。

2.高效的分布式锁

在设计分布式锁的时候，应该考虑分布式锁至少要满足的一些条件，同时考虑如何高效的设计分布式锁，以下几点是必须要考虑的：

(1) 互斥

在分布式高并发的条件下，最需要保证在同一时刻只能有一个线程获得锁，这是最基本的一点。

(2) 防止死锁

在分布式高并发的条件下，比如有个线程获得锁的同时，还没有来得及去释放锁，就因为系统故障或者其它原因使它无法执行释放锁的命令,导致其它线程都无法获得锁，造成死锁。所以分布式非常有必要设置锁的有效时间，确保系统出现故障后，在一定时间内能够主动去释放锁，避免造成死锁的情况。

(3) 性能

对于访问量大的共享资源，需要考虑减少锁等待的时间，避免导致大量线程阻塞。

所以在锁的设计时，需要考虑两点。

1、锁的颗粒度要尽量小。比如你要通过锁来减库存，那这个锁的名称你可以设置成是商品的ID,而不是任取名称。这样这个锁只对当前商品有效,锁的颗粒度小。

2、锁的范围尽量要小。比如只要锁2行代码就可以解决问题的，那就不要去锁10行代码了。

(4) 重入

我们知道ReentrantLock是可重入锁，那它的特点就是：同一个线程可以重复拿到同一个资源的锁。重入锁非常有利于资源的高效利用。关于这点之后会做演示。

3.基于Redis实现分布式锁

3.1 使用Redis命令实现分布式锁

3.1.1加锁

加锁实际上就是在redis中，给Key键设置一个值，为避免死锁，并给定一个过期时间。

使用的命令**：SET lock_key random_value NX PX 5000**

值得注意的是：

random_value 是客户端生成的唯一的字符串。

NX 代表只在键不存在时，才对键进行设置操作。

PX 5000 设置键的过期时间为5000毫秒。

也可以使用另外一条命令:SETNX key value

只不过过期时间无法设置。

这样，如果上面的命令执行成功，则证明客户端获取到了锁。

3.1.2解锁

解锁的过程就是将Key键删除，但要保证安全性，举个例子：客户端1的请求不能将客户端2的锁给删除掉。

释放锁涉及到两条指令，这两条指令不是原子性的,需要用到redis的lua脚本支持特性，redis执行lua脚本是原子性的。脚本如下：

if redis.call('get',KEYS[1]) == ARGV[1] then 
  return redis.call('del',KEYS[1]) 
else
  return 0 
end

这种方式比较简单，但是也有一个最重要的问题：锁不具有可重入性。

3.2使用Redisson实现分布式锁

3.2.1Redisson介绍

Redisson是架设在Redis基础上的一个Java驻内存数据网格（In-Memory Data Grid）。充分的利用了Redis键值数据库提供的一系列优势，基于Java实用工具包中常用接口，为使用者提供了一系列具有分布式特性的常用工具类。使得原本作为协调单机多线程并发程序的工具包获得了协调分布式多机多线程并发系统的能力，大大降低了设计和研发大规模分布式系统的难度。同时结合各富特色的分布式服务，更进一步简化了分布式环境中程序相互之间的协作。

3.2.2Redisson简单使用

Config config = new Config(); 
config.useClusterServers() 
.addNodeAddress("redis://192.168.31.101:7001") 
.addNodeAddress("redis://192.168.31.101:7002") 
.addNodeAddress("redis://192.168.31.101:7003") 
.addNodeAddress("redis://192.168.31.102:7001") 
.addNodeAddress("redis://192.168.31.102:7002") 
.addNodeAddress("redis://192.168.31.102:7003"); 

RedissonClient redisson = Redisson.create(config); 

RLock lock = redisson.getLock("anyLock"); 

lock.lock(); 

lock.unlock();

只需要通过它的 API 中的 Lock 和 Unlock 即可完成分布式锁，而且考虑了很多细节：

l Redisson 所有指令都通过 Lua 脚本执行，Redis 支持 Lua 脚本原子性执行。

l Redisson 设置一个 Key 的默认过期时间为 30s，但是如果获取锁之后，会有一个WatchDog每隔10s将key的超时时间设置为30s。

另外，Redisson 还提供了对 Redlock 算法的支持，它的用法也很简单：

RedissonClient redisson = Redisson.create(config); 
RLock lock1 = redisson.getFairLock("lock1"); 
RLock lock2 = redisson.getFairLock("lock2"); 
RLock lock3 = redisson.getFairLock("lock3"); 
RedissonRedLock multiLock = new RedissonRedLock(lock1, lock2, lock3); 
multiLock.lock(); 

multiLock.unlock();

3.2.3Redisson原理分析

(1) 加锁机制

线程去获取锁，获取成功: 执行lua脚本，保存数据到redis数据库。

线程去获取锁，获取失败: 一直通过while循环尝试获取锁，获取成功后，执行lua脚本，保存数据到redis数据库。

(2) WatchDog自动延期机制

在一个分布式环境下，假如一个线程获得锁后，突然服务器宕机了，那么这个时候在一定时间后这个锁会自动释放，也可以设置锁的有效时间(不设置默认30秒），这样的目的主要是防止死锁的发生。但是在实际情况中会有一种情况，业务处理的时间可能会大于锁过期的时间，这样就可能**导致解锁和加锁不是同一个线程。**所以WatchDog作用就是Redisson实例关闭前，不断延长锁的有效期。

如果程序调用加锁方法显式地给了有效期，是不会开启后台线程(也就是watch dog)进行延期的，如果没有给有效期或者给的是-1，redisson会默认设置30s有效期并且会开启后台线程(watch dog)进行延期

多久进行一次延期：（默认有效期/3），默认有效期可以设置修改的，即默认情况下每隔10s设置有效期为30s