文章清单
分布式事务是MySQL的一个重要考点，特别是单体架构变为微服务架构，高并发情况下，单一mysql撑不住，必须用mysql集群
【分布式事务 003】分布式事务保证服务间的数据一致性：使用MQ消息通知机制实现“实时性要求不高”的最大努力通知
【分布式事务 005】避免使用 二段式/三段式提交 分布式事务，使用ebay本地消息表
重要面试问题
面试问题1：强一致性、弱一致性、最终一致性？
强一致性：
定义：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。
优点：这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。
缺点：根据 CAP 理论，这种实现需要牺牲可用性，如Mysql Oracle自带XA事务。
弱一致性（弱一致性 仅仅是一个理论，没有实用价值，有实用价值的是特殊的弱一致性，最终一致性）：
定义：系统并不保证续进程或者线程的访问都会返回最新的更新过的值。用户读到某一操作对系统特定数据的更新需要一段时间，我们称这段时间为“不一致性窗口”。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。
最终一致性（弱一致性的一种特例）：
定义/特殊性：最终一致性是一种特殊的弱一致性。那么它特殊在哪里？我们说，“弱一致性是系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到”，最终一致性的特殊在于，系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。DNS 是一个典型的最终一致性系统。
特别注意，数据库的一致性只有唯二两个，强一致性和弱一致性，最终一致性是一种特殊的弱一致性，是弱一致性的一个子集合，不是和强一致性、弱一致性单独并列的第三种一致性。
最终一致性的特殊在于，系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。DNS 是一个典型的最终一致性系统。
面试问题2：解释一下事务和分布式事务？
问题：一句话将清楚 “事务和分布式事务”？
标准答案：
定义：事务是保证单数据库的数据一致性，分布式事务是保证多数据库的数据一致性。
实现方式：
前者用mysql自带的事务Transaction就可以实现，用自带的事务Transaction，将要原子化的操作包一层就好；
后者有不同实现方式，可以用主流数据库自带的XA 两段式分布式事务实现（XA强一致性,牺牲一定的可用性、性能、伸缩性），可以自己写sql语句、自己写后端代码来实现（ebay本地消息表、最大努力通知、TCC编程、最终一致性）（非XA最终一致性）。
面试问题3：七种分布式事务小结(面试宝典：记住下面三步就好)？
第一步，祭出7种分布式事务
mysql本身就提供了XA分布式事务，底层原理是 两段式 提交，
在数据库层面保证多数据源数据一致性：ebay本地消息表没有使用分布式事务保证多数据源数据一致性，而是使用 消息队列MQ作为通知，一个消息表保证幂等性，
最大努力通知，也是没有使用XA使用，两种方式：MQ通知、被通知放自己询问
在后端SOA接口层面保证多数据源数据一致性：TCC编程模式也没有使用MySQL的XA分布式事务，而是将一个接口变为三个接口try confirm cancel，用后端代码来处理
半消息/最终一致性，是对TCC的性能优化（TCC将一个接口变为两个接口 try-confirm 或者 try-cancel），使用核心功能TCC实现，非核心功能直接调用，核心功能使用MQ消息队列通知非核心功能所以，七种分布式事务：
MySql自带XA分布式事务：两段式、三段式、Mysql基于XA实现的分布式事务
不使用分布式事务，操作数据库mysql层面：ebay本地消息表、最大努力通知
不使用分布式事务，调用后端SOA接口层面：TCC编程模式、半消息/最终一致性对于TCC的性能优化
附上什么是XA？
XA定义：XA是由X/Open组织提出的分布式事务的规范(要想理解XA,先理解DTP)。
XA功能：XA规范主要定义了(全局)事务管理和(局部)资源管理器(RM)之间的接口，主流的关系型数据库产品都是实现了XA接口的，如mysql oracle（这一点很重要）。
第二步，比较5种分布式事务优点、缺点、强一致性+最终一致性、选用原则
XA分布式事务优点：分布式事务的强一致性，good.
XA分布式事务缺点：分布式事务的强一致性是以牺牲可用性、性能和可伸缩性为代价的。
不使用分布式事务，操作数据库mysql层面：ebay本地消息表、最大努力通知 优点：解除了两个数据库实例之间的紧密耦合，其性能和可伸缩性是分布式事务不可比拟的。
不使用分布式事务，操作数据库mysql层面：ebay本地消息表、最大努力通知 缺点：没有分布式事务的强一致性保证，使用上述方案在系统发生故障时，系统将短时间内处于不一致状态。但是，基于消息队列和消息应用状态表，最终可以将系统恢复到一致。
小结：XA分布式事务，强一致性；ebay本地消息表和最大努力通知都是使用消息队列，都是最终一致性（特殊的弱一致性。
选用原则（XA分布式事务 or ebay本地消息表/最大努力保证）：
使用分布式事务有助于简化应用开发，使用消息队列（ebay本地消息表/最大努力通知）明显需要更多的工作量，
对于时间紧迫或者对性能要求不高的系统，应采用分布式事务加快开发效率；
对于时间需求不是很紧，对性能要求很高的系统，应考虑使用消息队列方案（ebay本地消息表/最大努力通知）。
对于原有的使用分布式事务，且系统已趋于稳定，性能要求高的系统，则可以使用消息队列方案（ebay本地消息表/最大努力通知）进行重构来优化性能。
第三步，祭出数据库层面 和 SOA服务层面
至于 不使用分布式事务，调用后端SOA接口层面：TCC编程模式、半消息/最终一致性对于TCC的性能优化
这个无法比较，前面两种是操作数据库表，这个是操作SOA服务。
第四步，类比java多线程
两阶段提交和三阶段提交就是类似synchronized和lock包裹着要执行的代码，一定要原子性执行。
TCC的回滚操作是依赖于MySQL日志系统实现的，java多线程没有日志系统，无法提供回滚机制的支持，没有没有对应的。
最大努力通知类似于java种cas非阻塞同步，在硬件层面原子化操作，不断尝试，直到成功。
注意，第三个问题"七种分布式事务"，这个问题没有回答完毕，对于每一种具体的分布式事务实现方式，要看博客
对于两段式/三段式，看《分布式事务001 七种分布式事务》
对于Mysql基于XA实现的分布式事务，看单独博客
对于最大努力保证和ebay本地消息表，都是单独博客
对于TCC编程模型和最终一致性，看《分布式事务001 七种分布式事务》和《分布式事务002 分布式事务五种变迁》