如何快速安全地从概念进入产业化

这种情况下我们更加不能保证所有调用都成功。

由上面的例子下我们可以看出，随着业务发展，传统的单机事务已经无法满足我们的业务的需求，这个时候我们就需要分布式事务来保证。

分布式事务

摘抄一段 wiki 上解释。

A distributed transaction is a database transaction in which two or more network hosts are involved.

我们先来讲下实现分布式事务一些理论基础。

分布式事务技术理论

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

摘录极客时间从0开始学架构第22章解释

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

BASE 理论，分别是以下三个单词的缩写。

Basically Available(基本可用)：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。

Soft state(软状态)：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。

Eventually consistent(最终一致性)：最终一致是指经过一段时间后，所有节点数据都将会达到一致。
 

上图一次购买过程，商家余额表与用户余额表处于两个单独的数据库实例中，这样单独的事务能保证扣减商家余额或用户余额要么扣减成功，要么扣减失败。但是我们却无法保证两个事务同时成功或同时失败。

还有一种情况，随着系统越来越庞大，我们会选择将系统应用拆分多个微服务，让单个应用只操作一个数据源。这个时候我们就会碰到，一次业务调用，将会调用多个应用，每个应用单独操作数据源的情况，如下图。

 

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!