目录
分布式锁：
使用redis方式
zookeeper模式
分布式事务
seata方案
分布式锁：
在分布式环境中，服务都被分布在各个节点中，并且某个节点上的同一个服务还可能存在多个实例，那要保证在分布式系统中同一个资源只能被顺序访问的问题，此时sy锁就起不到作用了，因为此时的服务都是夸jvm的，
解决方案：参照图1
使用redis方式
（注1）
注：设置过期时间是为了再执行业务逻辑时出错没有执行到删除redis中的key而导致的死锁，
存在问题：
1、如果设置的锁时间已经过期了，但业务还没有执行完，还是会出现并发的问题
解决方案：参照图2
redisson框架，使用看门狗模式，如果发现锁还没有释放，则自动续期；（当然此方法也会存在问题：哨兵模式/主从模式切换master节点时会出现同时持有锁的问题，解决方案可以使用zookeeper）
即：当第一个线程获取到某个key的锁时，直接对该key执行加锁命令。在执行完业务后再进行解锁操作，当第一个线程还没有执行完时，第二个线程又执行到了该锁，则会进入一个等待状态，直到等到锁并执行（redisson自己已经实现了该功能，类似于一个等待队列）
图1
图2
1添加依赖
2、配置redissonClient的bean
3、使用案例
zookeeper模式
zookeeper的应用_子书少卿的博客
分布式事务
单个服务可以通过@Tran..注解可以保证，但不同服务之间保证同一个事务呢？
一致性：强一致性、弱一致性、最终一致性；
解决方案：
1、MQ最终一致性（比较复杂）
2、两阶段提交-2PC（百度）
不直接提交事务，而是告诉TM,A/B执行完之后如果有异常则根据XID标识进行回滚；（异步处理，不占用数据库链接，可以提供性能）
（A中会生成一个XId，并提交给TM，A调用B的时候会在消息头中带有该XId，B处理完事务后不管是成功还是失败都会告诉（带XId)给TM，由TM来完成事务的整体提交和回滚）
缺点：在AB都没有执行完的时候会一致占用链接；
3、seata方案（2PC优化）
直接提交事务（代理数据库的提交并不是提交到主数据库表而是插入的日志表），并记录日志，A/B执行完之后如果有异常则根据日志（undo_log）进行回滚，没有异常则提交整个事务；（异步处理，不占用数据库链接，可以提供性能）
问题：如果都提交了事务，在此期间其他事务也做了提交，如果再回滚的话会对之后提交的数据也进行了回滚，该如何处理？
：不是真正的提交到业务主表，而是通过代理数据源提交到了日志表，不会占用数据库的资源也不会提交事务，而是等处理完AB业务都统一处理；
seata方案
2、添加配置文件
3、代理数据源配置（独立事务）
4、日志表添加（回滚）
5、在业务的发起方法上添加@GlobalTran..来开启全局注解，seata会将事务的xid通过拦截器添加到调用其他服务的请求中，实现分布式事务；
注释：
1、setNx：相同的key只能被赋值一次，如果已经存在再次被赋值则失败，返回0；
2、幂等性：同一个接口相同的入参，调用一次和调用多次返回的结果一样（包括数据库数据一致）
问题：
1、redis设置了过期时间后，服务挂掉后重启，此时的数据是否还存在，是否还会根据过期时间自动过期？
2、‘set k v’ 能重新被赋值吗？‘set k v 过期时间’ 可以被重新赋值吗？
3、MQ的重复消费问题-幂等性问题
：引发原因：消息发送回调（ACK）时出现了延迟；
1、根据业务唯一编码判断
2、记录日志，判断是否处理过（redis记录日志）
3、数据库的乐观锁
资源参考自：分布式解决方案-Array-Java视频教程-后端开发-程序员研修院
