一文弄懂常用分布式事务解决方案

最新推荐文章于 2022-11-22 16:34:22 发布

HaiwiSong

最新推荐文章于 2022-11-22 16:34:22 发布

阅读量420

点赞数

分类专栏： Java 一文弄懂系列文章标签：分布式事务 CAP BASE

本文链接：https://blog.csdn.net/oTengYue/article/details/86750979

版权

38 篇文章 1 订阅

订阅专栏

20 篇文章 12 订阅

订阅专栏

CAP理论

在一个分布式系统(指互相连接并共享数据的节点的集合)中，当涉及读写操作时，只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个，另外一个必须被牺牲。

Consistency 一致性：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。（A read is guaranteed to return the most recent write for a given client. ）
Availability 可用性：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。（A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout). ）
Partition Tolerance 分区容忍性：当出现网络分区后，系统能够继续“履行职责”。（The system will continue to function when network partitions occur. ）

虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P(分区容忍)要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。
如果我们选择了 CA(一致性 + 可用性) 而放弃了 P(分区容忍性)，那么当发生分区现象时，为了保证 C(一致性)，系统需要禁止写入。
当有写入请求时，系统返回 error(例如，当前系统不允许写入)，这又和 A(可用性) 冲突了，因为 A(可用性)要求返回 no error 和 no timeout。
因此，分布式系统理论上不可能选择 CA (一致性 + 可用性)架构，只能选择 CP(一致性 + 分区容忍性) 或者 AP (可用性 + 分区容忍性)架构，在一致性和可用性做折中选择。

它的核心思想是即使无法做到强一致性(CAP 的一致性就是强一致性)，但应用可以采用适合的方式达到最终一致性。

Basically Available 基本可用：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
这里的关键词是“部分”和“核心”，实际实践上，哪些是核心需要根据具体业务来权衡。
Soft State 软状态：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。
Eventual Consistency 最终一致性：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
“一定时间”和数据的特性是强关联的，不同业务数据能够容忍的不一致时间是不同的。
而“最终”的含义就是不管多长时间，最终还是要达到一致性的状态。

常见的一致性模型：
强一致性：要求无论更新操作是在哪个数据副本上执行，之后所有的读操作都要能获得最新的数据。
弱一致性：在这种一致性下，用户读到某一操作对系统特定数据的更新需要一段时间，我们将这段时间称为"不一致性窗口"。
最终一致性：是弱一致性的一种特例，在这种一致性下系统保证用户最终能够读取到某操作对系统特定数据的更新(读取操作之前没有该数据的其他更新操作)。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

关注