分布式事务入门 一
您好，我是今夜写代码,今天学习下分布式事务相关理论，以及常见的解决方案，为后续掌握Seata分布式事务框奠定基础。
为什么需要分布式事务?
分布式事务主要由于存储资源的分布性，通常涉及多个数据库。 分布式事务一般存在如下场景
-
数据分库存储
当单个数据库实例的性能、连接数等无法满足应用数据存储和查询时，这时我们需要对业务数据进行分库存储，此时事务需要跨多个独立的数据库实例进行操作，保证多个数据库实例数据一致性问题，也就是分布式事务问题。
-
微服务架构
在微服务架构下，每个服务都有各自独立的数据库存储自身业务数据， 而完成某项功能可能涉及很多的服务的互相调用，然而每个服务只能控制自己本地事务的提交与回滚， 因此无法保证全局数据一致性，这也是典型的分布式事务问题。
消息队列异步更新
对于一些简单的业务，数据不要求强一致性时，我们可以使用消息队列异步通知下游系统更新数据。这种方式相信大家并不陌生。这种方式好处是:
-
解耦，实现简单
服务之间不需要耦合，扩展性好，新的服务依赖上游数据，只需要监听对应的消息即可。
-
性能较好
使用消息队列实现异步更新，避免同步阻塞，同时消息队列可以作为缓冲，能起到流量削锋作用。
不过这种方式只能保证数据最终一致性，由于消息队列本身可能存在延迟，失败重试等情况，对于一些强一致性场景是无法容忍的，比如电商场景很可能出现超卖问题。对于强一致性的场景，我们需要使用分布式事务保证数据的一致性。
XA协议
XA 协议（X/Open Distributed Transaction Processing, DTP）是一种用于管理分布式事务的标准协议，它使用两段提交（Two-Phase Commit, 2PC）保证事务的完整性，目前的分布式事务解决方案基本都是从两段提交演化来的。
主流的关系型数据库管理系统如MySQL 都支持XA 协议。
两段提交
-
准备阶段:事务协调者通知所有事务参与者准备分支事务，事务参与者执行事务，记录事务日志，但不提交事务，然后告知协调者通知事的执行结果。
-
提交/回滚阶段: 所有事务参与者明确返回成功 ，事务协调者发起提交事务指令，所有参与者执行提交事务操作。反之若有事务参与者反馈事务执行失败，事务协调者发起回滚指令，则所有事务参与者回滚事务。
两段提交存在的问题
-
同步阻塞
所有参与者事务都是同步阻塞的，这期间其他节点访问参与者占用的资源都会被阻塞。
-
单点故障问题
所有参与者需要等待事务协调者指令才能进行下一步，如果事务协调者出现单点故障,事务参与者将一直阻塞下去，资源也无法释放。
-
数据不一致
如果提交或者回滚阶段，如果部分参与者未收到通知，会一直阻塞下去，从而数据不一致。
三段提交
-
CanCommit (询问阶段):
事务协调者向事务参与者发送执行事务请求，事务参与者只需要回答是或不是，不需要正真事务操作，如果有参与者超时，则终止事务
-
PreCommit (准备阶段)
根据反馈结果决定是否继续执行，如果所有参与者反馈"Yes"，向事务参与者发送PreCommit请求，事务参与者收到请求执行事务， 写redo 和 undo日志，但不提交事务; 反之如果有参与者反馈"No" 或者有参与者超时没有反馈，则发送中断事务请求。
-
DoCommit （提交阶段）
如果PreCommit 所有事务参与者都返回成功，事务协议者发起提交事务请求，反之有参与者执行失败，或者超时未反馈结果发起执行回滚操作。
三段提交做了哪些改进?
增加CanCommit阶段，初步确认参与者是否可以执行事务，避免不必要的资源锁定，超时机制提前发现不健康节点。
三段提交每个阶段都有超时机制，利用超时机制解决避免长时间锁定资源，一旦超时仍可能出现数据不一致情况。 相对于两段提交，资源不会一直被锁定。
当然三段提交实现起来要比两段提交复杂,对于大多数应用来说，2PC仍然是处理分布式事务的标准方法。
未完待续
本文只是介绍分布式事务相关概念，实际使用更多的选择集成Spring Cloud Seata。Seata 是一个开源的分布式事务解决方案,并且我们可以根据实际场景选择不同的模式，如Saga模式、TCC模式。
