实际问题的产生：
实例：订单到支付（锁库存、发积分等业务多）
情况：
本地服务、操作本地数据库、本地事务无问题
调用远程服务，就出现了分布式事务，无法控制其他服务的回滚
产生分布式事务的最大原因：网络问题，
事务的基本性质：ACID
事务的隔离级别
本地事务失效问题：
问题：同一对象方法互调，覆盖事务
解决：使用代理对象调用事务方法，aspectj
@EnalbleAspectJAutoProxy（exposeProxy = true）
分布式事务的定理
CAP
BASE理论
强一致性、弱一致性、最终一致性
分布式事务的几种方案
1、2PC、3PC（自动TCC）
2、柔性事务、TCC补偿事务，
3、柔性事务、最大努力通知
4、柔性事务、可靠消息、最终一致性（异步确保性）
解决框架Seata
提供了AT、TCC、SAGA、XA事务模式
TC 事务协调器
TM 事务管理器
RM 资源管理器
步骤
1、创建数据库表
2、AT模式，每个微服务/库增加，创建UNDO_LOG表 （UNDO：回滚）
UNDO_LOG表有固定的业务字段
3、安装SEATA-server
4、整合
4.1，pom依赖
4.2、根据依赖的版本、启动对应版本server
registry_config文件
配置注册中心（例如nacos）、
指定相关配置 file-config，例如NIO，TCP、store（db-store）
每个微服务增加file.config(修改service微服务对应名字),registry.conf
4.3启动server，登录nacos，查看serverAddr—即seata服务器
5、开启：
所有想用到分布式事务的微服务，都需要seata作为代理数据源
6、给分布式大事务入口（方法）标记全局事务
给每个远程的小事务配置单事务（方法）
@GlobalTransication
@Transicastion（本地自己处理）
模式适用
AT、阻塞，不适合高并发（2PC，TCC不适合高并发）。例如后台管理系统
使用MQ消息队列处理、避免事务阻塞
如何保证消息可靠性
1、消息丢失
1.1情况：网络错误，消息没抵达服务器：
解决：Try catch 捕获发送失败，发送消息都记录日志，数据库中保存每个消息的详细信息，
定期扫描数据库，将失败的消息再发送。
1.2情况：Broker宕机
解决：使用发送者的确认机制，confirmCallback、returnCallback监听
1.3 手动ACK
2、消息重复
2.1情况：ack失败、会重复消费。消费者的业务消费接口应该设计为幂等性、防重表、判断是否redelivered
2.2消费失败，自动发出，正常
3、消息积压
3.1 消费者宕机
3.2 消费者消费能力不足
3.3 发送者发送流量太大
解决：1、增加消费者，上线专门的队列消费服务器，先取存，后离线处理。2、限流