1 常见分布式实现方案介绍

1.1 XA方案

有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务不适合高并发场景，严重依赖数据库层面，同步阻塞问题；协调者故障则所有参与者会阻塞

1.2 TCC方案

严重依赖代码补偿和回滚，一般银行用，和钱相关的支付、交易等相关的场景，我们会用TCC Try，对各个服务的资源做检测，对资源进行锁定或者预留 Confirm，在各个服务中执行实际的操作 Cancel，如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，即执行已操作成功的业务逻辑的回滚操作

可靠消息最终一致性方案
1）：本地消息服务本地消息表其实是国外的 ebay 搞出来的这么一套思想。主动方是认证服务，有个消息异常处理系统，mq，还有消息消费端应用系统，还有采集服务；

在我认证返回数据中如果有发票是已经认证的，在处理认证数据的操作与发送消息在同一个本地事务中，业务执行完，消息数据也同时存在一条待确认的数据；
发送消息给mq，，mq发送消息给消息消费端服务，同时存一份消息数据，然后发送给采集服务，进行抵账表更新操作；
采集服务逻辑处理完以后反馈给消息消费端服务，其服务删除消息数据，同时通知认证服务，把消息记录改为已确认成功费状态；
对于异常流程，消息异常处理系统会查询认证服务中过期未确认的消息发送给mq，相当于重试
2）：独立消息最终一致性方案：A 主动方应用系统，B消息服务子系统，C消息状态确认子系统，C2消息管理子系统 D 消息恢复子系统，mq ，消息消费端E ，被动系统F

流程：
A预发送消息给B，然后执行A业务逻辑，B存储预发送消息，A执行完业务逻辑发送业务操作结果给B，B更新预发送消息为确认并发送消息状态同时发送消息给mq，然后被E监听然后发送给F消费掉
C：对预发送消息异常的处理，去查询待确认状态超时的消息，去A中查询进行数据处理，如果A中业务处理成功了，那么C需改消息状态为确认并发送状态，然后发送消息给mq；如果A中业务处理失败了..那么C直接把消息删除即可.
C2 ：查询消息的页面，对消息的可视化，以及批量处理死亡消息；
D：B给mq放入数据如果失败，，通过D去重试，多次重试失败，消息设置为死亡
E：确保F执行完成，发送消息给B删除消息
优化建议：
（1）数据库：如果用redis，持久化要配置成appendfsync always，确保每次新添加消息都能持久化进磁盘
（2）在被动方应用业务幂等性判断比较麻烦或者比较耗性能情况下，增加消息日志记录表.用于判断之前有无发送过；
最大努力通知性（定期校对）
（1）业务主动方完成业务处理之后，设置时间阶梯型通知规则向业务活动的被动方发送消息，允许消息丢失.
（2）被动方根据定时策略，向主动方查询，恢复丢失的业务消息
（3）被动方的处理结果不影响主动方的处理结果
（4）需增加业务查询，通知服务，校对系统服务的建设成本
（5）适用于对业务最终一致性的时间敏感度低，跨企业的业务通知活动
（6）比如银行通知，商户通知，交易业务平台间商户通知，多次通知，查询校对等