分布式事务处理

学习思路：

分布式事务处理一共三种方式：
第一种： 事件驱动框架模式
第二种：补偿模式
第三种：TCC模式(try confirm cancel)

关于三种模式的详细介绍可以看视频田向阳视频讲解分布式事务

一、事件驱动框架

事件驱动框架模式：
这个是需要做大个颠覆，主要有两点需要注意：
1、保证事件的投递 (方式一：采用投递前生成一条记录，投递后有确认，如果长时间没有确认，确认了证明投递成功，如果长时间没有确认会超时，超时时，调用原服务接口，看是否处理完，如果处理完就直接确认，否则就代表失败，直接丢弃。方式二： 把服务的逻辑处理和event store放在同一个事务里面，这个所有的事件都会存储到events表中，这样就能通过数据库的事务一致性保证业务逻辑处理完把事件记录到events表中了。然后通过一个服务一个进程或者线程不断的从表中拿数据进行发布事件到其他的微服务)
2、消费事件保证不要重复（如果保证不要重复？第一：尽量保证操作的幂等性。第二：如果开始处理一个事件是首先查询以前处理的事件的ID看是否重复，如果重复直接返回上次处理结果，如果不重复再进行处理）
事件驱动框架处理需要有一套事件驱动框架，这个可以看开源的实现，如下进行学习参考
微服务事件源处理方案中的框架

二、补偿模式

补偿模式： 何为补偿模式，就是一个人需要做三个事情当做一个事务： 定火车 定航班 订酒店，如果前两个成功，最后一个失败了如何处理？就把前面进行取消掉，这就是补偿模式。
1、补偿模式的要点在于你每次操作完成以后都要记录这些业务流水，比如 定火车，定航班，订酒店，这是对应的业务流水，这些都要记录下来，如果后期出现问题，可以调用补偿模式进行补偿，调用补偿模式也会出现很多问题：
比如调用出错，补偿的过多导致服务压力大，或者出现http 500错误，这些都要根据具体的情况选择不同的重试机制。比如失败一次重试30秒一次，第二次1分钟一次，也有最大重试次数限制等，需要好好设计。
2、要点二就是补偿服务表的设计，两种方式第一种一张大表，前面记录服务编号，操作，状态，后续记录事件信息，这样有性能问题，而且和业务不相关，难设计。一般用第二种方式两张表，一张平台的表记录服务编号，处理事件表以及流水的表，流水表就是和业务相关的，可以进行动态设计，能够结合业务，所以一般用这种方式，
但是目前没有发现好的开源框架。

三、TCC模式

TCC模式就是try confirm cancel，这个操作原理是提前锁定，比如我上美团订三张电影票，美团会给我锁定三张，等我支付完成以后，再直接更新为卖出，这个锁定有超时什么的设置，而且也会出现问题，如果出现问题就会进行对账，这是终极模式，对账一般分为对总账或者对流水。这是TCC模式的精髓！可以参考开源的TCC模式框架，目前没有发现好的，可以看看这个研究下：
TCC框架研究

微服务的最难点在于分布式事务的处理：

如何处理？
查询关键字

2PC 分布式事务

这一篇讲的真好，首先读这个

田向阳分布式事务
以下是事件源处理机制，比较麻烦，需要引入单独事件源框架进行处理，算是目前的一个方案！

** 微服务架构必须解决这三个问题 **

• 拆分
• 事务
• 查询

下面这几篇文章通过引入事件源处理框架的方式解决了这三个问题
微服务事务处理思路上
微服务事务处理思路下
微服务事件源处理方案中的框架

干货 微服务下的分布式事务管理
参考思路：

大牛陈皓关于分布式事务处理的解读