分布式、CAP和BASE理论基础-不念博客

在计算机科学领域，分布式系统是一门极具挑战性的研究方向，也是互联网应用中必不可少的优化实践，而 CAP 理论和 BASE 理论则是分布式系统中的两个关键的概念。

1、什么是事务

但是在这之前要先知道什么是事务。

什么是事务？

举个生活中的例子：你去小卖铺买东西，“一手交钱，一手交货”就是一个事务的例子，交钱和交货必须全部成功，事务才算成功，任一个活动失败，事务将撤销所有已成功的活动。明白上述例子，再来看事务的定义：

事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败

2、本地事务

在计算机系统中，更多的是通过关系型数据库来控制事务，这是利用数据库本身的事务特性来实现的，因此叫数据库事务，由于应用主要靠关系数据库来控制事务，而数据库通常和应用在同一个服务器，所以基于关系型数据库的事务又被称为本地事务

2.1. 数据库事务特性

A（Atomic）：原子性，构成事务的所有操作，要么都执行完成，要么全部不执行，不可能出现部分成功部分失败的情况
C（Consistency）：一致性，在事务执行前后，数据库的一致性约束没有被破坏。比如：张三向李四转100元，转账前和转账后的数据是正确状态这叫一致性，如果出现张三转出100元，李四账户没有增加100元这就出现了数据错误，就没有达到一致性
I（Isolation）：隔离性，数据库中的事务一般都是并发的，隔离性是指并发的两个事务的执行互不干扰，一个事务不能看到其他事务运行过程的中间状态。通过配置事务隔离级别可以避脏读、重复读等问题
D（Durability）：持久性，事务完成之后，该事务对数据的更改会被持久化到数据库，且不会被回滚

数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元，该执行单元中的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚

3. 分布式事务

软件系统由原来的单体应用转变为分布式应用，下图描述了单体应用向微服务的演变

分布式系统把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务，例如用户注册送积分事务、创建订单减库存事务，银行转账事务等都是分布式事务

本地事务依赖数据库本身提供的事务特性来实现，因此以下逻辑可以控制本地事务：

begin transaction;
//1.本地数据库操作：张三减少金额
//2.本地数据库操作：李四增加金额
commit transation;

分布式环境，事务变成下边这样:

begin transaction;
//1.本地数据库操作：张三减少金额
//2.远程调用：让李四增加金额
commit transation;

可以想象，当远程调用让李四增加金额成功了，由于网络问题远程调用并没有返回，此时本地事务提交失败就回滚了张三减少金额的操作，此时张三和李四的数据就不一致了。

因此在分布式架构的基础上，传统数据库事务就无法使用了，张三和李四的账户不在一个数据库中甚至不在一个应用系统里，实现转账事务需要通过远程调用，由于网络问题就会导致分布式事务问题。

4. CAP定理

CAP是是分布式系统设计中非常重要的一个原则,它是指 **Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性)**三个基本原则。

4.1. Consistency(一致性)

一致性:是当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态,从而确保数据准确性

在分布式系统中，广泛的一致性分为三种，分别是强一致性、弱一致性和最终一致性。

4.1.1. 强一致性

强一致性要求用户在分布式系统中访问数据时，不管是哪个节点的响应，数据都应该完全一致

比如转账系统张三给李四转账1000块，那么张三账户减少1000块，同时李四账户响应减少100块，即要么账户 A 和账户 B 的余额都更新成功，要么都不更新。

这样可以避免出现转账金额在系统中“消失”的情况，从而保证了数据的一致性，确保了银行业务的正常运行。

4.1.2. 弱一致性

弱一致性是指在分布式系统中，允许在一定条件下出现数据不一致的情况，但最终数据会趋于一致，不保证实时性和强制性。

这种一致性级别通常用于需要高可用性和性能的场景，允许在一段时间内出现数据不一致，但最终数据会在系统内部达到一致状态

比如公众号在发布消息后，不同的粉丝可能在不同的时间内收到该消息。

这是因为消息推送可能会经过多个节点和服务，不同节点的处理速度和网络延迟会导致消息的推送时延不一致。

4.1.3. 最终一致性

最终一致性是指分布式系统中的数据副本在一段时间内可以存在不一致的情况，但最终会趋于一致状态。

这种一致性级别通常用于分布式系统中的数据复制和同步场景，系统会在一定的时间范围内保证数据最终达到一致状态，但不保证实时性和强制性。

比如当你的朋友对帖子进行点赞后，该信息需要被同步到所有观看该帖子的用户界面上。

这个同步过程可能也是异步的，并且可能会受到网络延迟等因素的影响，导致一段时间内点赞信息在不同用户界面上不一致，尽管在点赞过程中可能会出现一定的时间窗口内数据不一致的情况，但社交媒体平台会通过一定的机制和策略来保证最终所有帖子的点赞数量都达到一致状态。

这种最终一致性的特性使得社交媒体平台能够在分布式环境下提供可靠的服务，保证用户的交互体验

注意:一般的业务系统基于性价比的考量，绝大多数都是采用最终一致性作为分布式系统的设计思想。

而 CAP 理论里的一致性，则要求是强一致性。

正如官方文档中描述的那样：All nodes see the same data at the same time，所有节点在同一时间内数据完全一致

4.2.Availability(可用性)

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

可用性确保了系统的稳定性和可靠性，它描述的是系统能够很好地为用户服务，不会出现用户操作失败或者访问超时的情况，影响用户体验。

4.3.Partition tolerance(分区容错性)

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

5. CAP特点

思考:CAP可以同时成立吗

不可以，在CAP理论实际告诉我们，在分布式系统中，我们最多可以同时满足两个特性，无法同时满足三个

在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务又必须对外保证服务。

因此Partition Tolerance（分区容错性）不可避免。当节点接收到新的数据变更时，就会出现问题了：

如果此时要保证**Consistency(一致性)**，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。
如果此时要保证**Availability(可用性)**，就不能等待网络恢复，那服务之间就会出现数据不一致。

也就是说，在P一定会出现的情况下，A和C之间只能实现一个。

CAP是一个已经被证实的理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。

它可以作为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9（99.99..%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证P和A，舍弃C强一致，保证最终一致性