目前各大型网站及应用都是分布式部署,分布式场景中数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance),最多只能同时满足两项。在互联网领域的绝大多数的场景中,都需要牺牲强一致性来换取系统的高可用性(可用性),系统往往只需要保证“最终一致性”,只要这个最终时间是在用户可以接受的范围内即可。
单机环境
单机环境下只有当前JVM虚拟机A(或一个服务器)中的多个线程对同一个Object(共享资源)进行操作时,可以采用同步互斥(就是只有同一时间只有一个线程对共享资源进行事务操作)的方式,我们常用的方式就是采用加锁的方式(synchronized和lock)解决,虽然不能保证数据的强一致性,但是能够保证数据的最终一致性。
非单机环境下如果两个虚拟机A和B(或两个服务器)同时对同一个共享资源(数据库中的一张表或者数据库中的一行数据进行操作),那么这时候就不能采用加锁的方式了,因为多个服务器的内存是不共享的,加锁只能锁住当前服务器的进程和线程,加锁的方式就局限在解决一个虚拟机中的线程安全问题了, 这时候就出现了分布式锁,用来解决分布式系统之间访问共享数据,共享数据在同一时间只能被某个服务器中某单个进程/线程操作,从而保证数据的一致性
基于数据库的分布式锁(可通过数据库的悲观锁/乐观锁来实现的分布式锁)
基于Redis的分布式锁
基于Redis实现分布式锁执行流程:
1、虚拟机实例A根据Hash算法选择Redis节点(Redis采用的是集群部署,每个服务器都是一个节点),执行Lua脚本加锁(就是通过setnx方法,即set一个key(主键id)到Redis当中,判断Redis中是否有当前key,没有,就返回1,表示加锁成功,有就返回0,表示加锁失败),并且设置锁的过期时间。当虚拟机A对共享资源上锁成功过后,就拥有了对共享数据的操作权限,然后就可以对共享数据的操作处理,执行事务处理。
问题:在从Redis获取锁的过程和进行设置锁的过期时间过程中出现宕机,就会出现锁一辈子不会被释放?出现死锁问题?
这时候就需要保证获取锁和设置锁的过期时间两行代码的原子性,就是要么同时成功,要么同时失败,如何实现呢?-----这时候只要保证将两行代码变成一行代码即可。
原本的setnx和expire是两行代码
if(jedis.setnx(lock_stock,1) == 1){ //获取锁
//=========在这里出现宕机了=====死锁问题出现了=========
expire(lock_stock,5) //设置锁超时
try {
业务代码
} finally {
jedis.del(lock_stock) //释放锁
}
}
通过set变成一行代码过后,解决了死锁问题
if(set(lock_stock,1,"NX","EX",5) == 1){ //获取锁并设置超时
try {
业务代码
} finally {
del(lock_stock) //释放锁
}
}
2、这时候如果虚拟机B也需要对共享资源进行操作,也去执行lua脚本进行加锁(就是采用setnx的方式--通过set一个key到redis,判断redis中是否已经存储了这个key(行数据的主键id)),如果查询到redis中没有,就会返回1表示加锁成功,如果有就会返回0表示加锁失败 ,这就能保证共享资源同一时间不会被多个虚拟机同时操作。
3、当虚拟机A执行完对自己已经加锁的共享资源执行操作完成之后,必须要执行DEL释放锁,不然其他虚拟机包括虚拟机A都不能再对当前共享资源进行加锁操作,
问题:虚拟机A能保证会执行完成过后一定执行DEL释放锁吗? 答案是:不一定的
4、当虚拟机A执行对共享资源事务操作完成之后,在执行DEL释放锁之前,代码出现问题,抛出异常就会出现这种问题,虚拟机A就永远不能执行DEL释放锁了,就会导致后续上锁都会失败。
问题:所以就出现上面这个执行流程,如何解决呢?
5、这时候起初指执行lua脚本加锁的时候,存储一个过期时间,当不能主动进行DEL释放锁时,到达Redis设置的过期时间,锁就会过期。
这个时候又会出现另一个问题? 就是虚拟机A在设置的过期时间以内还没有执行完对共享资源的操作,锁就过期了,如何解决呢?
6、这时候就会执行最后一个流程,后台守护线程(类似于Redission内部提供一个监控锁的看门狗),来定期的检查锁是否存在,如果存在,延长key的过期时间,还需要判断事务是否还在正常执行,如果是异常已经抛出异常,就不用进行后台守护线程了,然后等待锁自动过期。
说这么多?其实就是明白其执行原理,而实际开发过程中,大佬们已经使用Redission封装好了上面的具体实现细节。
Redission实现分布式锁【封装了基于Redis的分布式锁】
Redission简单理解为就是操作Redis的一个工具包,让我们使用Redis更加简单,让使用者能够将精力更集中地放在处理业务逻辑上。
Redisson实现分布式锁
1、Redisson加锁自动有过期时间30s,监控锁的看门狗发现业务没执行完,会自动进行锁的续期(重回30s),这样做的好处是防止在程序还没有执行结束,锁自动过期被删除问题
2、当业务执行完成不再给锁续期,即使没有手动释放锁,锁的过期时间到了也会自动释放锁
// 获取锁
RLock lock = redisson.getLock(LOCK_KEY);
try {
// 加锁
lock.lock();
int s = Integer.parseInt(Objects.requireNonNull(stringRedisTemplate.opsForValue().get(REDIS_KEY)));
if (s > 0) {
// 扣库存
s--;
System.out.printf("秒杀商品个数剩余:" + s + "\n");
// 更新库存
stringRedisTemplate.opsForValue().set(REDIS_KEY, String.valueOf(s));
} else {
System.out.println("活动太火爆了,商品已经被抢购一空了!");
}
} catch (Exception e) {
System.out.println(Thread.currentThread().getName() + "异常:");
e.printStackTrace();
} finally {
// 释放锁
lock.unlock();
}
基于Zookeeper的分布式锁
ZooKeeper是一个分布式的协调服务,Zookeeper是基于CP,注重数据的一致性,若主机挂掉则Zookeeper不会对外进行提供服务了,需要选择一个新的Leader出来才能提供服务,不保证高可用性。简单来说zookeeper=文件系统+监听通知机制。
Zookeeper数据模型
Zookeeper会维护一个具有层次关系的树状的数据结构,它非常类似于一个标准的文件系统,如下图所示:同一个目录下不能有相同名称的目录节点
每个子目录项如 NameService 都被称作为 znode(目录节点),和文件系统一样,我们能够自由的增加、删除znode,在一个znode下增加、删除子znode,唯一的不同在于znode是可以存储数据的。
有四种类型的znode:
- PERSISTENT-持久化目录节点 客户端与zookeeper断开连接后,该节点依旧存在
- PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点,客户端与zookeeper断开连接后,该节点依旧存在,只是Zookeeper给该节点名称进行顺序编号
- EPHEMERAL-临时目录节点,客户端与zookeeper断开连接后,该节点被删除
- EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点,客户端与zookeeper断开连接后,该节点被删除,只是Zookeeper给该节点名称进行顺序编号
监听通知机制
客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、被删除、子目录节点增加删除)时,zookeeper会通知客户端。
实现方案:临时顺序目录节点+监听机制
在项目中可以使用curator,这个是Apache封装好的基于zookeeper的分布式锁方案