分布式锁的场景及解决方案

分布式锁的使用场景：超卖问题

库存一定的商品，在并发请求时即存在超卖问题，例如：大促、秒杀

单进程解决方案

在同一进程下，只需要通过java内置的锁Synchronized和ReentranLock即可。

其核心思想就是保证多个线程互斥访问count变量，从而解决超卖问题。

集群场景

问题分析

为了提升性能，减缓单机压力，会将该程序部署到多台机器上运行。这时三个用户的操作就可能打在三台机器上。在集群场景下由于资源不共享，如果依然只采用java单进程的锁，那么每个程序都会获取到一把锁，多个程序同时访问库存，造成超卖问题。

解决方案

想要解决问题，依然是找到一种互斥访问库存的解决方案。

在单机单进程环境下，所有的资源都是存在jvm中，jvm具有上帝视角，因此可以实现jvm加锁互斥访问。

但在多机集群环境下，程序彼此之间互不相识，资源独立。因此需要找到一份公共的空间去沟通协调，类似于生活中的第三方组织介入，这个第三方可以通过Redis/MySql/Zookeeper来实现。这也就是分布式锁的实现思路。

当多个进程访问库存时，首先通过第三方获取到一把分布式锁，获取锁成功的才可以访问库存，否则需等待锁释放。

Redis实现分布式锁 

通过Redis中的缓存来实现分布式锁，即setNx命令，通过该命令可以设置一份key-value至redis中，多个程序访问库存时，通过判断是否设置过库存相关的key来判断是否执行命令，达到分布式锁的目的。

//加锁
private boolean tryLock(final String key, final String value) {
    try {
        MiddlewareCacheResult result
            = middlewareCache.setNx(key, value, exipireTime);
        return result.isSuccess();
    } catch (Exception e) {
        log.error("setNX error, key : {}", key,e);
    }
    return false;
}

//释放锁
public static void releaseLock(String lockKey){
    delete(lockKey);
}

在设置过期时间后又会导致两个问题。

        锁已经过期释放，但程序还没有执行结束。

由于程序未执行结束，过期释放了锁，同时另一个程序获取到了锁，此时第一个程序执行结束，再次释放了第二个程序的锁，导致程序逻辑错误。

解决方案：

        当其他程序尝试获取锁时，如果程序未执行结束，则延长锁的过期时间。

public boolean tryLock(int expireSecond) throws InterruptedException{
    //锁到期时间
    if (this.setNX(lockKey, value, expireSecond)) {
        // lock acquired
        this.expire(lockKey,expireMsecs/1000);
        return true;
    }
    return false;
}

设置value为当前用户相关信息，每次获取锁时判断下value值是否和当前用户信息匹配，防止锁释放的乱套。

redis锁性能提升思路

可以使用分段锁机制，当商品库存非常多时，比如库存有100个，可以每10个库存加一把锁，比如id在1-10是第一把锁，id在11-20为第二把锁，通过10把锁来增加高并发的思路。

Redis集群问题

在Redis集群中使用主从机制时，A程序在主节点获取到锁后，数据还未同步至从节点，此时主节点宕机，另一个B程序在从节点中请求锁，由于数据尚未同步，在B程序获取锁成功，A程序和B程序同时访问，依然造成超卖问题。

红锁

为了解决上述集群问题，引入红锁机制，红锁中多个节点独立，没有主从依赖关系。一般都是奇数个节点。

1.获取当前时间。

2.依次获取N个节点的锁。

3.判断是否获取锁成功。 如果client在上述步骤中获取到了(N/2 + 1)个节点锁，并且每个锁的过期时间都是大于0的，则获取锁成功，否则失败。失败时释放锁。

4.释放锁。 对所有节点发送释放锁的指令。

红锁问题

在上述红锁中依然会出现问题，比如对于如下五个节点，当某程序获取到A、B、C三个节点的锁后，这时C节点宕机，同时立即被人重启，这时另外一个程序获取C节点的锁时成功（由于刚刚被重启），该程序同时获取D、E的锁成功，它得到了C、D、E的锁，按照约定获取超过半数节点的锁即可执行，两个程序同时访问互斥资源，依然会造成超卖问题。

因此一般会有约定，当redis挂掉后，会通过手册约定一个时间后再重启，一般在该重启时间后程序锁会过期或者运行完毕，不会对程序造成影响，一般不能立即重启。

总结

通过简单的超卖问题，引入一系列解决方案，伴随着场景越来越复杂，也会带来越来越多的细节问题，在实际开发中，要多思考高并发带来的问题，注意互斥资源的访问。