详解分布式事务与应用

分布式事务介绍

百度百科:分布式事务
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单的说就是：需要保证一个事务的操作分散到不同的应用或者节点上了。分布式事务就是为了保证这种情况下的数据一致性。比如，你把应用soa服务化了，那么订单和库存拆分出了不同的中心服务，同时对订单和库存进行操作，就涉及到了库存和订单的数据库操作，两个数据库要保证数据一致性，就需要分布式事务。

CAP理论

百度百科:cap原则
CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。

分布式事务解决方案

XA方案/两阶段提交方案：
两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。依赖数据库层面解决数据库之间的分布式事务。
ps:我没用过。

TCC方案：
tcc即try、confirm、cancel，也属于两段式提交，但是是基于应用解决分布式事务问题的。
1.try阶段：各个服务进行检测与资源锁定或预留，判断是否有能力完成。都有能力，则进入确认阶段。
2.confirm阶段：对资源进行操作。各个接口都成功后操作
3.cancel阶段：代码回滚confirm操作。任何一个操作失败后，通过错误类型判断是否重试，还是进行补偿回滚。
这种方式需要写很多补偿代码，每一个操作都要有对应的补偿代码。

本地消息表：
ebay的思想：
1.A本地事务进行一个操作，将操作记录到数据库消息表中
2.定时扫描A消息表，通知B进行操作
3.B接收到操作指令，往B消息表中插入一条信息，保证密等，接着做B的业务处理
4.B执行成功后，更新自己的消息表和A的消息表
5.B执行失败，回滚B消息表。回到第二步骤。
保证了消息一致性，B失败了，A会一直扫描通知。过于依赖数据库消息表。

可靠消息最终一致性方案：
就是说，不用数据库来做消息表了，直接用mq来做消息表。典型的有RocketMq。

努力通知方案：
做过支付宝或者微信支付的知道，支付成功或失败会进行接口通知，通知失败会进行重试。
1.A执行业务成功后，将消息存入队列与库中。
2.通知B接口我成功了，你可以进行下一步操作了。
3.B成功，业务完成。B失败，A一直通知，或者进行失败操作。

人工补偿方案：
如果业务不大，内容不多，人工补偿也不失为一个好方案。系统失败率没有那么高。

选择

1.业务不大，人工补偿OK的，还不影响性能。
2.严格事务，比如资金等，TCC方式。
3.一般的事务场景可以使用可靠消息最终一致性。

**ps:**如果您有任何问题，请留言，个人技术不到位，所以写的东西存在很多问题，记录一下自己的思路。如果有不足还请多指点，十分感激。我会及时补充和修改、回复。
好了，今天不写了，去锻炼一下。加油。