redis-lock

The most elegant Redis distributed lock implementation.

可能是最优雅的redis分布式锁实现吧，关于锁的实现可参考可重入锁，该分布式锁支持重入机制

分布式锁的实现条件

• 1、互斥性，和单体应用一样，要保证任意时刻，只能有一个客户端持有锁

• 2、可靠性，要保证系统的稳定性，不能产生死锁

• 3、一致性，要保证锁只能由加锁人解锁，不能产生A的加锁被B用户解锁的情况

不同的人可能有不同的实现逻辑

分布式环境下，数据一致性问题一直是一个比较重要的话题，而又不同于单进程的情况。 分布式与单机情况下最大的不同在于其不是多线程而是多进程。 多线程由于可以共享堆内存，因此可以简单的采取内存作为标记存储位置。 而进程之间甚至可能都不在同一台物理机上，因此需要将标记存储在一个所有进程都能看到的地方

常见的是秒杀场景，订单服务部署了多个实例。 如秒杀商品有4个，第一个用户购买3个，第二个用户购买2个，理想状态下第一个用户能购买成功，第二个用户提示购买失败，反之亦可。 而实际可能出现的情况是，两个用户都得到库存为4，第一个用户买到了3个，更新库存之前，第二个用户下了2个商品的订单，更新库存为2，导致出错

分布式锁实际是要让多机远程访问一个加锁的共享资源，redis可以做分布式锁是因为其可以对同一个key的访问加锁， 这跟单不单线程没有关系。memcached可以 ，mysql可以，zookeeper也可以

准备工作

• 在pom中直接引入引入spring-data-redis依赖,也可自行扩展Jedis。

加锁模式

• RedisLock.lock：直到加锁成功。
• RedisLock.tryLock：尝试加锁。

使用优点

加锁在一个原子操作中完成，具有redis锁失效，以及本地解锁。 会有人有疑问这样和setNx 加上 失效时间有何区别，下面进行对比。

• redis-lock 支持锁重入，使用方式与 ReentrantLock 类似。
• setNx无法解决当前锁在分布式情况下被另外的客户端解锁的可能。

存在缺点

• client1 在Redis一个主节点获得了一个锁。
• 主节点挂了，而主从节点的写同步还没完成（异步复制）。
• 从节点被提升为主节点，client2 就有可能获得和 client1 相同的锁。