背景:
笔者所在的公司,上周末经历了一场大促活动后,系统暴露出这样一个问题:分布式锁使用的zk锁,由于当天大促用户量比较多,系统疯狂的加锁释放锁,最后zk承受不住这么大的压力宕机。由于马上就要618,为了避免再次发生这样的事情,公司决定把所有系统的zk锁都替换为高性能的Redis锁。
在这里简单的提一下,zk锁性能比redis低的原因:zk中的角色分为leader,flower,每次写请求只能请求leader,leader会把写请求广播到所有flower,如果flower都成功才会提交给leader,其实这里相当于一个2PC的过程。在加锁的时候是一个写请求,当写请求很多时,zk会有很大的压力,最后导致服务器响应很慢。
正题:
什么情况下需要加锁?
当多个线程、用户同时竞争同一个资源时,需要加锁。比如,下订单减库存,抢票,选课,抢红包等。如果在此处没有锁的控制,会导致很严重的问题,下订单减库存的时候不加锁,会导致商品超卖;抢票的时候不加锁,会导致两个人抢到同一个位置;选课的时候没有锁的控制,导致选课成功的人数大于教室的座位数;抢红包时没有锁的控制,抢到红包的金额大于红包的实际金额。
什么是分布式锁?
学过JAVA多线程的朋友都知道,为了防止多个线程同时执行同一段代码,可以用synchronized关键字或JAVA API中ReentrantLock类来控制。
但是目前几乎任何一个系统都往往部署多台机器的,单机部署的应用很少,synchronized和ReentrantLock发挥不出任何作用,此时就需要一把全局的锁,来代替JAVA中的synchronized和ReentrantLock。
当Thread1线程获取到锁,执行锁中的代码,其他线程或其他机器再次请求该锁,发现锁被Thread1占用,加锁失败。当Thread1释放锁,其他线程则可以获取到锁并执行相应的操作。
我们可以用Jedis中是setnx命令来构建这把锁,首先,我列举一些错误的构建锁的方式:
错误例子1
Long lock= jedis.setnx(key,value); if(lock>0){ //执行业务逻辑 }
通过setnx命令创建一个key、value,如果key不存在,则加锁成功。这样做有什么问题呢?如果执行加锁操作成功,在释放锁的时候,系统宕机,导致这个key永远不会被del掉,也就是说其他线程一直获取不到锁,
导致死锁发生。为了避免这种情况,请看下面的代码
错误例子2
Long lock= jedis.setnx(key,value); if(lock>0){ jedis.expire(key,expireTime); }
和上面的例子类似,唯一不同的是这里多了一步设置key过期时间的操作。如果在del的时候系统宕机,等过期时间一到,Redis会删除这个key。
其他线程可以再次获取锁。这样就可以万无一失了吗?这里有一个问题,如果在第一步setnx成功后,突然网络闪断,expire命令执行失败,同样也有死锁的风险。这两步并不具备原子性,不保证全部成功或全部失败。
正确的构建方式
public static boolean getDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) { String result = jedis.set(lockKey, requestId, "NX