1. 基础用法

由于数据库和应用服务的双重水平、垂直切分，会导致一个完整业务需要跨多个数据处理的情况，很多并发情况下会发生数据一致性问题，为了解决该问题，本项目引入了Redisson作为分布式锁解决方案，项目地址https://github.com/redisson/redisson。

在需要加锁的地方，首先生成lockKey，然后调用tryLock获取状态，该方法返回的状态必须做判断，失败的时候也一定要做好合适的失败处理：

需要注意的是：锁和解锁必须成对出现！

2. 分布式锁的时间问题

上面的组件是经过我们封装过的，实际上，在发起锁(tryLock)的时候，我们传入了两个参数：

default_wait_time：锁等待时间，该时间内无法得到锁，则获取失败（false）

default_expire_time：锁失效时间，超过该时间，则会自动释放锁

这两个参数在很多分布式锁框架里面都存在，这里解释一下。

第一个很好理解，当并发量很大时，锁的争抢非常严重，执行体等待时间过长，会导致调用端耗时严重，等待时间过短，则失败率会提高，目前我默认设置3秒，即：3秒内拿不到锁，则返回失败，调用端可能需要发起重试或者直接失败（假如允许失败的话）。

第二个参数会有一些坑点存在，比如某个执行逻辑很耗时，超过了我们的锁失效时间，此时会自动释放锁，那么新的线程/进程会拿到该锁，最终导致前一个执行体未执行完，新的执行就开始了，进而产生数据不一致的情况。目前我项目里面设置的是30秒，有兴趣可以看RedissonLockComponent。

不过，假如用的是用的Redisson，从内部源码看，它会在默认过了2/3时间的时候自动续命。此时你唯一要祈祷的是：Redis服务千万不要挂了。。。