背景
目前开发过程中，按照公司规范，需要依赖框架中的缓存组件。不得不说，做组件的大牛对CRUD操作的封装，连接池、缓存路由、缓存安全性的管控都处理的无可挑剔。但是有一个小问题，该组件没有对分布式锁做实现，那就要想办法依靠缓存组件自己去实现一个分布式锁了。
什么，为啥要自己实现？有现成的开源组件直接拿过来用不就行了，比如Spring-Integration-Redis提供RedisLockRegistry，Redisson，不比自己去实现快的多。那我得声明一下，本人也不喜欢重复造轮子。具体原因呢，首先是项目中的缓存组件是不能替换的，连接池还可能没有办法复用，其次就是如果对开源组件实现原理不熟悉，那么出了问题，维护起来又需要更多成本。
先说一下当前需要分布式锁的两个场景，一个是微信端access_token刷新（分布式锁可以保证access_token只刷新一次，刷新完成之后放入缓存，其他请求直接从缓存读取）；一个是分布式部署的定时任务（分布式锁可以保证同一时刻只有一个节点的定时任务执行）。
什么是分布式锁
在单机部署的情况下，要想保证特定业务在顺序执行，通过JDK提供的synchronized关键字、Semaphore、ReentrantLock，或者我们也可以基于AQS定制化锁。单机部署的情况下，锁是在多线程之间共享的，但是分布式部署的情况下，锁是多进程之间共享的。那么分布式锁要保证锁资源的唯一性，可以在多进程之间共享。
分布式锁特性
- 保证同一个方法在某一时刻只能在一台机器里一个进程中一个线程执行；
- 要保证是可重入锁（避免死锁）；
- 要保证获取锁和释放锁的高可用；
分布式锁实现方案对比
- Mysql：一般项目都会用到缓存，不可能都用数据库，强依赖数据库不现实。虽然实现乐观锁和悲观锁很简单，但是性能不佳。
- Redis：首先集群可以提高可用性，其次借助Redis实现分布式锁也很简单，另外有很多框架已经帮我们实现好了，直接拿来用就可以了，很方便。同时定期失效的机制可以解决因网络抖动锁删除失败的问题，所以我比较倾向Redis实现。
- Zookeeper：和Mysql一样，不可能为了用分布式锁而去新增并维护一套Zookeeper集群，其次实现起来还是比较复杂的，实现不好的话还会引起“羊群效应”。如果不是原有系统就依赖Zookeeper，同时压力不大的情况下，一般不使用Zookeeper实现分布式锁。
分布式锁考虑要点
- 锁释放（finally）；
- 锁超时设置；
- 锁刷新（定时任务，每2/3的锁生命周期执行）；
- 如果锁超时了，防止删除其他线程的锁（其他线程会拿到锁），考虑 value值用线程id标识，当前线程释放锁的时候要判断是否为当前线程的线程id；
- 可重入；
Redis分布式锁
RedisLockRegistry
RedisLockRegistry是spring-integration-redis中提供redis分布式锁实现类。主要是通过redis锁＋本地锁双重锁的方式实现的一个比较好的锁。
OBTAIN_LOCK_SCRIPT是一个上锁的lua脚本。KEYS[1]代表当前锁的key值，ARGV[1]代表当前的客户端标识，ARGV[2]代表过期时间。
基本逻辑是：根据KEYS[1]从redis中拿到对应的客户端标识，如已存在的客户端标识和ARGV[1]相等，那么重置过期时间为ARGV[2]；如果值不存在，设置KEYS[1]对应的值为ARGV[1]，并且过期时间是ARGV[2]。
获取锁的过程也很简单，首先通过本地锁（localLock，对应的是ReentrantLock实例）获取锁，然后通过RedisTemplate执行OBTAIN_LOCK_SCRIPT脚本获取redis锁。
为什么要使用本地锁呢，首先是为了锁的可重入，其次是减轻redis服务压力。
释放锁的过程也比较简单，第一步通过本地锁判断当前线程是否持有锁，第二步通过本地锁判断当前线程持有锁的计数。
如果当前线程持有锁的计数 > 1，说明本地锁被当前线程多次获取，这时只释放本地锁（释放之后当前线程持有锁的计数-1）。
如果当前线程持有锁的计数 = 1，释放本地锁和redis锁。
RedisLockRegistry使用如上所示。
首先定义RedisLockRegistry对应的Bean，需要依赖redis的ConnectionFactory。
然后在服务层中注入RedisLockRegistry实例。
通过lock方法和unlock方法将业务逻辑包起来，需要注意的是unlock方法要写在finally代码块中。
Redisson
Redisson是架设在Redis基础上的一个Java驻内存数据网格（In-Memory Data Grid）。
充分的利用了Redis键值数据库提供的一系列优势，基于Java实用工具包中常用接口，为使用者提供了一系列具有分布式特性的常用工具类。
使得原本作为协调单机多线程并发程序的工具包获得了协调分布式多机多线程并发系统的能力，大大降低了设计和研发大规模分布式系统的难度。
同时结合各富特色的分布式服务，更进一步简化了分布式环境中程序相互之间的协作。
首先感受一下通过Redisson Api使用redis分布式锁。
定义RedissonBuilder，通过redis集群地址构建RedissonClient。
定义RedissonClient类型的Bean。
业务代码里，通过RedissonClient获取分布式锁。
由于对Redisson分布式锁实现原理了解的也不是很透彻，这里推荐一篇文章：Redisson 分布式锁实现分析。
Redisson和RedisLockRegistry对比
- RedisLockRegistry通过本地锁（ReentrantLock）和redis锁，双重锁实现，Redission通过Netty Future机制、Semaphore （jdk信号量）、redis锁实现。
- RedisLockRegistry和Redssion都是实现的可重入锁。
- RedisLockRegistry对锁的刷新没有处理，Redisson通过Netty的TimerTask、Timeout 工具完成锁的定期刷新任务。
- RedisLockRegistry仅仅是实现了分布式锁，而Redisson处理分布式锁，还提供了了队列、集合、列表等丰富的API。
动手实现分布式锁
实现原理
本地锁（ReentrantLock）+ redis锁
获取锁lua脚本
锁刷新lua脚本
锁释放lua脚本
本地锁定义
每一个lock key对应唯一的一个本地锁
线程标识定义
分布式环境下，每一个线程对应一个唯一标识
锁刷新定时任务定义
通过JDK ConcurrentTaskScheduler完成定时任务执行，ScheduledFuture完成定时任务销毁。其中taskId对应线程标识。
定义分布式锁注解
分布式锁切面
通过RedisLock注解实例lockInfo获取到锁key值、锁过期时间信息。
获取锁过程
- 通过lockInfo.key()方法获取到锁key值，通过锁key值拿到对应的本地锁（ReentrantLock）
- 本地锁获取锁对象
- 进入获取redis锁的循环
- 通过缓存服务组件执行获取锁的lua脚本
- 如果获取到redis锁，判断当前线程是否第一次获取到锁并且开启了锁刷新，相应的注册锁刷新定时任务
- 如果没有获取到redis锁，休眠lockInfo.sleep()毫秒的时间，再次重试
释放锁过程
- 获取到当前锁key值对应的本地锁
- 判断当前线程是否为本地锁锁的持有者
- 如果本地锁的重入次数大于1，则只释放本地锁
- 如果本地锁的重入次数等于1，释放本地锁和redis锁
分布式锁测试
定义测试类，测试方法注上@RedisLock注解，制定锁的key值为 "redis-lock-test"，测试方法内随机休眠。
开启20个线程，同时调用测试方法。
多线程redis分布式锁测试结果如下。
定义可重入测试类，方法内获取当前代理对象，递归调用测试方法。
测试方法中，调用可重入测试类注有@RedisLock的测试方法。
分布式锁可重入测试结果如下。
分布式锁实际应用
定义access_token刷新服务
refreshAccessToken方法上标注@RedisLock注解，表明此方法在分布式环境下会串行执行。
首先从缓存里获取access_token。
如果缓存里的access_token为空或者和失效的access_token相等，通过TokenAPI生成新的access_token并放入缓存。
如果缓存里的access_token不为空并且和失效的access_token不相等，直接返回缓存里的access_token。
定义access_token获取服务
如果缓存中的access_token为空，直接刷新access_token并放入缓存。
如果缓存中的access_token不为空且和失效的access_token相等则刷新access_token并放入缓存，否则直接返回缓存中的access_token。
分布式锁应用场景
在分布式环境下，涉及线程间并发问题和进程间并发问题都是可以通过分布式锁解决的。如果是单节点线程之间共享资源的并发问题可以通过JDK提供的线程锁来解决，如果是多节点多线程之间共享资源的并发问题就需要借助分布式锁。比如最常见的秒杀、抢红包，后台服务中涉及到库存扣减、金额扣减、以及其他高并发串行化场景的操作都可用分布式锁来解决问题。本文讲述的例子主要是应用在微信公众号和微信小程序access_token刷新、微信分享jsapi_ticket刷新，分布式锁可以保证access_token和jsapi_ticket在高并发下只有一个线程去执行刷新动作，避免多次刷新后access_token或者jsapi_ticket失效的问题。
