拒绝躺平，如何使用AOP的环绕通知实现分布式锁

如何在分布式环境下，像用synchronized关键字那样使用分布式锁。比如开发一个注解，叫@DistributionLock，作用于一个方法函数上，每次调方法前加锁，调完之后自动释放锁。

可以利用Spring AOP中环绕通知的特性，完全满足上面的要求。

1、Maven依赖

这里采用redisson这个第三方库来做redis的分布式锁，redis配置不在这里展开，可以参考文末贴出的代码地址或具体可以看这篇 https://zhaoxiaobin.net/6ba1dd4958f4/

2、开发自定义注解

这里按照锁的粗细粒度分为两种模式：

1. 粗粒度：由注解中的value字段指定，编译阶段就确定了，同一个方法（业务）共享该锁。不管是谁调这个方法，都是按串行执行。
2. 细粒度：方法的参数列表中的一个参数作为锁的key值，比如一个编号、一个流水号等等业务唯一参数。主要应用在如果同一个（同一组）交易允许不同人同时做，但同一个人必须串行执行的场景；由index指定作为key的形参位置。

3、开发切面

4、模拟测试扣库存

业务操作

模拟发起交易

这里用Java8的并行流并发去发50个交易来模拟扣20的库存，不加锁的情况下：

给increment方法加上分布式锁注解，再测试：

以上案例不是太严谨，为了测试方便，只是测了单机并没有测集群的效果。有条件可以连上数据库并起多个服务去扣库里的数据，看分布式锁效果如何。

5、分布式锁的安全性

相信有不少同学都知道Redis的分布式锁不是那么的万无一失；比如主从切换导致锁丢失，还有NPC等问题影响锁的安全性，具体可以参考这篇 https://zhaoxiaobin.net/Redis/Redis分布式锁真的安全吗？讲的最详细的一篇（转载）/

建议：

1. 对于要求数据绝对正确的业务，在资源层一定要做好「兜底」，比如数据库的乐观锁、类似CAS等操作。
2. 使用分布式锁，在上层完成「互斥」目的，虽然极端情况下锁会失效，但它可以最大程度把并发请求阻挡在最上层，减轻操作资源层的压力。

代码地址

• github：https://github.com/senlinmu1008/redis-action/tree/master/redisson
• gitee：https://gitee.com/ppbin/redis-action/tree/master/redisson