重点讲redis 分布式锁,后两种持续更新中。。。
锁:
当在单进程系统中,用到多线程时,多个线程改变一个变量,这时候,需要对变量或者代码块进行同步,避免多线程引发的线程不安全问题,即数据不一致。而同步的本质就是加锁,目的是为了实现多个线程同一时刻操作同一代码的时候,只能有一个线程执行任务。
对于单机来讲,可以加关键字 synchronized 或者 volatile 来实现同步也可以通过互斥锁。
分布式:
分布式,与单机的区别是,单机是一个进程,当然可以是多线程,但分布式是多进程。主要体现在集群上。
单机可以共享堆内存,多进程的话,就需要用一个所有机器都能看到的地方。
根据CAP理论,即:一致性(Consistency),可用性(Availability),分区容错性(Partition tolerance)
这三个基本需求,最多只能同时满足其中两项。
对于分布式系统而言,分区容错性是基础,是必不可少的,所以只能在 C 、A 中取舍了。在互联网领域的绝大多数的场景中,都需要牺牲强一致性来换取系统的高可用性,系统往往只需要保证最终一致性。
分布式锁:
一般分布式锁有三种实现方式:
1. 基于数据库实现分布式锁
2. 基于缓存(redis,memcached,tair)实现分布式锁
3. 基于Zookeeper实现分布式锁
分布式锁一般满足几个条件:
- 互斥性。在任意时刻,只有一个客户端能持有锁。
- 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
- 具有容错性。只要大部分的Redis节点正常运行,客户端就可以加锁和解锁。
- 解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了
一:基于数据库表做乐观锁
乐观锁的特点先进行业务操作,不到万不得已不去拿锁。即“乐观”的认为拿锁多半是会成功的,因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。
一般是根据数据库表的版本号(version)控制的, ---- 经典的ABA问题,银行转账问题。
操作:
先执行select操作,查询当前数据的数据版本号,再根据这个版本号为条件,进行数据库操作(update),并跟新版本号。
二:redis 分布式锁
注: 该加锁方法仅针对单实例 Redis 可实现分布式加锁,对于 Redis 集群则无法使用
基本锁
- 原理:利用Redis的setnx如果不存在某个key则设置值,设置成功则表示取得锁成功。
- 缺点:如果获取锁后的进程,在还没执行完的时候挂调了,则锁永远不会释放。
改进型
- 改进:在基本型是锁上的setnx后设置expire,保证即使获取锁的进程不主动释放锁,过一段时间后也能自动释放。
- 缺点:
- setnx与expire不是一个原子操作,可能执行完setnx该进程就挂了。
- 当锁过期后,该进程还没执行完,可能造成同时多个进程取得锁。(貌似这个问题目前还没有很优雅的解决方案)
再改进
- 改进:利用Lua脚本,将setnx与expire变成一个原子操作,可解决一部分问题。
- 缺点:还是锁过期的问题。
Lua脚本:获取锁对应的value值,检查是否与clientId相等,如果相等则删除锁(解锁)
我们将Lua代码传到jedis.eval()方法里,并使参数KEYS[1]赋值为lockKey,ARGV[1]赋值为clientId。eval()方法是将Lua代码交给Redis服务端执行。
注:执行eval()方法可以确保原子性。就是在eval命令执行Lua代码的时候,Lua代码将被当成一个命令去执行,并且直到eval命令执行完成,Redis才会执行其他命令
加锁代码:
String result = jedis.set(lockKey, clientId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, milliseconds);
if (LOCK_SUCCESS.equals(result)) {
return Boolean.TRUE;
}
return Boolean.FALSE;
private static final String SET_IF_NOT_EXIST = "NX";
private static final String SET_WITH_EXPIRE_TIME = "PX";
private static final String RELEASE_LOCK_SCRIPT = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
jedis.set方法的参数介绍:
- 第一个为key,我们使用key来当锁,因为key是唯一的。
- 第二个为value,我们传的是clientId,很多童鞋可能不明白,有key作为锁不就够了吗,为什么还要用到value?原因就是我们在上面讲到可靠性时,分布式锁要满足第四个条件解铃还须系铃人,通过给value赋值为requestId,我们就知道这把锁是哪个请求加的了,在解锁的时候就可以有依据。clientId可以使用UUID.randomUUID().toString()方法生成。
- 第三个为nxxx,这个参数我们填的是NX,意思是SET IF NOT EXIST,即当key不存在时,我们进行set操作;若key已经存在,则不做任何操作;
- 第四个为expx,这个参数我们传的是PX,意思是我们要给这个key加一个过期的设置,具体时间由第五个参数决定。
- 第五个为time,与第四个参数相呼应,代表key的过期时间。
解锁代码:
Object result = jedis.eval(RELEASE_LOCK_SCRIPT, Collections.singletonList(lockKey),
Collections.singletonList(clientId));
if (RELEASE_SUCCESS.equals(result)) {
return Boolean.TRUE;
}
return Boolean.FALSE;
这样redis分布式锁就OK了
完整锁代码链接:redis分布式锁工具类
若是多机器部署redis,可以参考 redisson,这是Redis官方提供的Java组件。https://github.com/redisson/redisson
参考:https://www.cnblogs.com/suolu/p/6588902.html
http://www.cnblogs.com/seesun2012/p/9214653.html
https://www.cnblogs.com/szlbm/p/5588543.html
https://www.cnblogs.com/linjiqin/p/8003838.html