redis分布式锁失效问题-幂等性

一.与Transcational注解同时使用

如果是自定义的切面，reidis切面类要加@Order(Ordered.HIGHEST_PRECEDENCE)，

如果 RedisLockAspect 没有设置 @Order(Ordered.HIGHEST_PRECEDENCE) 注解，而且同时和 @Transactional 注解一起使用，那么事务注解 @Transactional 可能会在获取锁之前就开启了事务，从而导致无法保证先获取锁再开启事务的顺序。

这是因为 Spring AOP 的默认执行顺序是根据切面的加载顺序来确定的，而不是根据注解的顺序。如果没有明确指定切面的执行顺序，而且 RedisLockAspect 和 @Transactional 事务注解共同作用于同一个方法，那么事务切面可能会先于锁切面执行，导致事务在获取锁之前就已经开启了。因此，为了确保先获取锁再开启事务的顺序，需要在 RedisLockAspect 上添加 @Order(Ordered.HIGHEST_PRECEDENCE) 注解，以确保该切面在执行时具有最高的优先级。这样可以保证在方法执行之前先获取锁，然后再由 @Transactional 切面来管理事务的开启、提交或回滚。

总之，通过正确设置切面的执行顺序，结合 @Transactional 注解和分布式锁的获取，可以确保在高并发环境下先获取锁再开启事务，从而有效地控制并发和保证数据一致性。

二.日期字段是datetime

背景：jmeter 500并发测试接口出现重复插入。接口逻辑如下

服务器查看日志如下

数据库插入结果如下

2023-09-04 17.56.41.729 到 2023-09-04 17.56.42.015插入的数据，数据库的create_time都是按2023-09-04 17.56.42存储的。在高并发场景下，由于datetime会向上取整，出现重复插入

解决方案：datetime类型的create_time建表时数据类型改为datetime(3),可以支持到毫秒