分布式事务-基础篇

前置知识

事务的概念

事务的特性

SQL中的事务隔离级别

MySQL本地事务的的实现方案（Redo log 与 undo log）

为什么会产生分布式事务？

跨库操作以及分库分表

微服务远程调用

CAP理论（分布式事务的基本理论）

概念

在一个分布式系统中，一致性、可用性、分区容错性最多能实现其中两点，无法三者兼顾。

百科词条：https://baike.baidu.com/item/CAP%E5%8E%9F%E5%88%99[1]

数据一致性：所有节点在同一时间数据完全一致，不存在中间状态。解释：例如订单系统和库存系统的数据更新，库存和订单有关联，两者之间的数据要保持同步。

可用性：保证每个请求不管成功或者失败都有响应。解释：（1）返回结果必须在合理的时间以内，这个合理的时间是根据业务来定的。业务说必须 100 毫秒内返回，合理的时间就是 100 毫秒，需要 1 秒内返回，那就是 1 秒，如果业务定的 100 毫秒，结果却在 1 秒才返回，那么这个系统就不满足可用性。

分区容错性:系统中任意信息的丢失或失败不会影响系统的继续运作。解释：分布式系统中存在多个节点，节点之间通过网络进行通信，当节点与节点之间的通信出现问题，此时，就称当前的分布式系统出现了分区。那么，什么是容忍性？它是说，如果出现了分区，分布式系统还要继续运行， 不能因为分区问题，整个分布式系统就瘫痪。

为什么无法同时满足C A P？

首先，CAP的三种特性不是boolean类型，即可用或不可用，一致或不一致，分区容忍和不容忍这类二选一的选项。

单独从CAP定理来讲，满足数据一致性的前提是分布式系统具备分区容错性，否则无法保证数据一致性。数据一致性指的是强一致性，即各节点数据都要同步完成返回客户端。在这种情况下，就会牺牲到“高可用”的特性。若要满足高可用的特性，则需要部分节点的数据更新异步处理（弱一致性）,此时部分节点可能会读到旧数据。

所以若要满足高可用的条件，就需要牺牲“强 一致性”。

CAP定理值得是强一致性，高可用，分区容错性。

BASE理论

BASE是 basic available(基本可用)、soft state（软状态）、Eventually Consistent（最终一致性）。

基本可用:1. 功能上的损失：例如在电商网站，在大促期间，部分消费者会被引导到一个降级页面。2. 响应时间上的损失：例如正常情况0.5秒响应，而基本可用状态下2秒返回。

软状态：允许数据存在中间状态，即多个不同节点的数据同步存在数据延时。

最终一致性：

数据同步最终保持一致。（1）因果一致性：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。

（2）读己之所写：节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。

（3）会话一致性：会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

（4）单调读一致性：如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

（5）单调写一致性：一个系统要能够保证来自同一个节点的写操作被顺序的执行。

分布式事务解决方案

刚性事务

刚性事务满足CAP的CP。

XA协议（2pc、JTA、JTS）以及3pc。

刚性事务由于同步阻塞，处理效率低， 不适合大型网站分布式场景。

柔性事务

要求最终一致性。

柔性事务分为补偿型、异步确保型、最大努力通知型。

柔性事务：TCC/FMT 、saga、本地事务消息、消息事务。

References

[1] https://baike.baidu.com/item/CAP%E5%8E%9F%E5%88%99: https://baike.baidu.com/item/CAP原则