redis和zk分布式锁使用场景

前言

本文介绍下分布式锁的一个使用场景
分享本文的缘由是因为今天在写代码时需要处理一个原子性问题，场景是：业务功能需要先查询数据，再根据数据判断是否要更新数据，在这个查询+更新的过程必然会存在高并发下的原子性问题

那么如何解决这个问题呢，那么就要说到我们的主角：分布式锁了

分布式锁介绍

分布式锁：即在多集群多节点环境下确保只有一个线程可以拿到锁，防止并发出现的问题，类似于synchronized，只不过synchronized不能处理多节点的问题

解决上述问题的一种解决方式就是使用分布式锁，虽然性能会比较低，但是笔者的场景是一个统计功能，并且是异步的，所以并不影响性能
核心代码如下：

场景介绍

try {
	// 这里可以根据业务场景做分段锁，可以适当提升性能
	String lock = "lock_key";
	long keyValue = System.currentTimeMillis();
	// 获取锁，超时时间60秒每隔0.5秒尝试获取一次，60秒后没获取到则放弃
	boolean getLock = redisUtils.getLockByInterval(lock,keyValue,60,0.5,0);
	if(getLock) {
		xxx
	}
} catch (Exception e) {
  log.error("异常：", e);
} finally {
    if(getLock) {
        redisUtils.unLock(lock,keyValue);
    }
}

RedisUtils类getLockByInterval

  /**
     * 获取锁，如果没获取到那么每隔interval秒重试一次，重试直到timeout秒
     * @param key
     * @param value
     * @param timeout 超时时间（单位秒）
     * @param interval 超时时间（单位秒）
     * @param currentTime 当前时间，调用时传0，只用于递归时间
     * @return
     */
    public boolean getLockByInterval(String key,Object value,int timeout,double interval,double currentTime) {
        if(currentTime > timeout) {
            return false;
        }
        // 相当于redis的setnx命令
        boolean getLock = redisTemplate.opsForValue().setIfAbsent(key,value,timeout, TimeUnit.SECONDS);
        if(!getLock) {
            //没有拿到锁就间隔interval再次尝试获取锁,直到总时间大于timeout
            try {
                Thread.sleep(Double.valueOf(interval*1000).longValue());
            } catch (InterruptedException e) {
                log.error("RedisUtils getLockByInterval error:",e);
            }
            currentTime += interval;
            // 递归
            return getLockByInterval(key,value,timeout,interval,currentTime);
        }
        return true;
    }

上述代码其实还是不够完美，当并发量足够大时可能存在某线程在超时时间内还是没有抢占到锁，因为获取锁的机制是按照间隔时间来获取的，并且属于非公平锁，即不是先到的线程有权利优先获取锁，这里可以看到redis的分布式锁并不是很友好，这里再介绍下zookeeper的分布式锁

分布式锁对比

redis分布式锁：通过redis通过的sexNx命令实现，即当key不存在时调用setNx返回true，否则返回false，获取不到锁的线程只能轮询去尝试获取锁
优点：性能高，使用简单，在允许偶发锁失效的场景下推荐使用
缺点：通过轮询抢占锁的机制不是很可靠，当某线程占用锁时间较长时可能导致其他线程抢占锁失败

zookeeper分布式锁：zk的分布式锁机制是利用zk的临时有序节点，即多个线程同时抢占锁会创建多个节点如a1->a2->a3->a4->a5…,只有拿到第一个节点的线程获得锁，里面节点注册是的watch机制，即a1使用完后会释放当前节点，同时watch下一个节点a2，依次类推
优点：不依靠轮询抢占锁，依靠的是节点间的通信，比较可靠，当业务场景要求比较高是推荐使用
缺点：性能不如redis缓存锁高