方案一；2pc 两阶段提交 <数据库层面>
需要一个事务协调者
第一阶段 询问阶段，事务协调者挨个询问能否成功执行
第二阶段 提交阶段，如果其中一个服务失败了就全部回滚，之后再重试机制。 如果第一阶段所有服务都能成功则全部事务提交。
协调者是单点，可能出现单点故障
方案二： TCC Try-Confirm-Cancel <业务层面>
Try是预留 将资源锁定限制住
Confirm是确认操作，就是正常操作
Cancel 是撤销操作，将之前的操作撤销
难点在于业务上的定义，对于所有服务的每⼀个操作你都需要定义三个动作分别对应 Try - Confirm - Cancel 。 因此 TCC 对业务的侵⼊较⼤和业务紧耦合，需要根据特定的场景和业务逻辑来设计相应的操作。
方案三：本地消息表
每个服务维护一个本地消息表，执行操作的同时往本地消息表里插入一条操作的记录，记录操作成功和失败。
会有后台任务定时去查看每个服务的本地消息表，筛选出来操作失败的记录，重新执行，或者选择回滚
本地消息表为了最终一致性，可以容忍短暂的不一致性
方案四：MQ实现消息事务
2PC 是⼀种强⼀致性事务，不过还是有数据不⼀致，阻塞等⻛险，⽽且只能⽤在数据库层⾯。
⽽ TCC 是⼀种补偿性事务思想，适⽤的范围更⼴，在业务层⾯实现，因此对业务的侵⼊性较⼤，每⼀ 个操作都需要实现对应的三个⽅法。
本地消息表、事务消息和最⼤努⼒通知其实都是最终⼀致性事务，因此适⽤于⼀些对时间不敏感的业务。