分布式事务：两个理论

Posted 2021-04-25 Java平台框架技术共享

说完分布式事务的三个概念，我们再来说说分布式事务中的两个理论。

1. CAP理论

1.1 理解CAP

CAP是 Consistency、Availability、Partition tolerance三个词语的缩写，分别表示一致性、可用性、分区容忍 性。

为了方便对CAP理论的理解，我们结合电商系统中的一些业务场景来理解CAP。如下商品信息管理的执行流程图：

整体执行流程如下：（1）商品服务请求主数据库写入商品信息。（2）主数据库向商品服务响应写入成功。（3）商品服务请求从数据库读取商品信息。

1.1.1 C-Consistency：一致性

一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意节点读取到的数据都是最新的状态。

上图中，商品信息的读写要满足一致性就是要实现如下目标：

（1）商品服务写入主数据库成功，则向从数据库查询新数据也成功。

（2）商品服务写入主数据库失败，则向从数据库查询新数据也失败。

那么如何实现一致性呢？写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入成功之前，向从数据库查询到旧数据。

基于以上描述，我们可以得出一致性的特点：

（1）由于存在数据同步的过程，写操作的响应会有一定的延迟。

（2）为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源。

（3）如果请求数据同步失败的节点则会返回错误信息，一定不会返回旧的数据。

1.1.2 A-Availability：可用性

可用性是指任何操作都可以得到响应结果，且不会出现响应超时或响应错误。

上图中，商品信息读取满足可用性就是要实现如下目标：

（1）从数据库接收到数据查询的请求则立即能够响应数据查询结果。

（2）从数据库不允许出现响应超时或响应错误。

那么如何实现可用性？

（1）写入主数据库后，由于要保证从数据库的可用性，不可将从数据库的资源进行锁定。（与C矛盾，这也是为什么后面会说任何一个系统都不可能同时满足CAP三个特性）

（2）即使数据还没有同步到从数据库，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照约定返回一个默认信息，但不能返回错误或响应超时。（这点很重要，是可用性的核心。）

1.1.3 P-Partition tolerance：分区容忍性

通常分布式系统的各个节点部署在不同的子网，这就是网络分区。不可避免的会出现由于网络问题而导致节点之间通信失败，此时仍可对外提供服务，这就叫分区容忍性。

上图中，商品信息读写满足分区容忍性就是要实现如下目标：

（1）主数据库向从数据库同步数据失败不影响读写操作。

（2）其一个节点挂掉不影响另一个节点对外提供服务。

那么如何实现分区容忍性？

（1）尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据库，这样节点之间能有效的实现松耦合。

（2）从数据库多节点部署，其中一个节点挂掉其它节点仍然可以提供服务。

1.2 CAP组合方式

不管CAP如何进行组合，在所有分布式事务场景中不会同时具备CAP三个特性，因为在具备了P的前提下C和A是不能共存的。

1.2.1 AP

放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。

上边的商品管理，完全可以实现AP，前提是只要用户可以接受所查询的到数据在一定时间内不是最新的即可。通常实现AP都会保证最终一致性，后面讲的BASE理论就是根据AP来扩展的，一些业务场景 比如：订单退款，今日退款成功，明日账户到账，只要用户可以接受在一定时间内到账即可。

1.2.2 CP

放弃可用性，追求一致性和分区容错性。比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。

1.2.3 CA

放弃分区容忍性，即不进行分区，不考虑由于网络不通或节点挂掉的问题，则可以实现一致性和可用性。那么系统 将不是一个标准的分布式系统，我们最常用的关系型数据就满足了CA。

1.3 总结

CAP是一个已经被证实的理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。它可以作为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景，节点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9（99.99..%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证P和A，舍弃C强一致，保证最终一致性。

2. BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个词语的缩写。BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性。

• 基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如：电商网站交易付款出现问题，但是依然可以正常浏览商品。
• 软状态：由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如发票的"开票中"、“作废中”等状态。
• 最终一致性：最终一致是指经过一段时间后，所有节点数据都将会达到一致。如发票的"开票中"状态，最终会变为“已开票”或者"开票失败"，使发票状态与实际开票结果达成一致，但需要一定时间的延迟、等待。

END

如有收获，请划至底部，点击"在看"。万分感谢！