CAP和BASE理论

原创已于 2024-03-22 17:05:51 修改 · 834 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #java #分布式事务 #seata

于 2022-04-30 13:35:25 首次发布

分布式事务专栏收录该内容

3 篇文章

订阅专栏

CAP和BASE理论

一、概述

事务是数据库运行的一个逻辑工作单元，在这个工作单元内的一系列SQL命令具有原子性操作的特点，也就是说这一系列SQL指令要么全部执行成功，要么全部回滚不执行。如果是不执行，那么对于数据库中的数据来说，数据没有发生任何改变。

在 Mysql事务原理中说个事务的四大特性ACID

原子性（Atomic）：事务必须是原子工作单元，对数据进行修改，要么全部执行，要么全部都不执行
隔离性（Isolation）：由并发事务所做的修改必须与任何其他并发事务所做的修改隔离
持久性（duration）：事务完成之后，对系统的影响是永久性的，不会被回滚
一致性（Consistent）：原子性，隔离性，持久性，最后都是为了实现一致性。事务在完成时，必须使所有数据都保持一致状态，事务结束时所有的内部数据结构都必须是正确的；如果事务是并发多个，系统也必须如同串行事务一样操作。

而分布式微服务架构中，如何保证分布式事务的完整性？

二、二阶段提交模型

在分布式事务中，多个小事务的提交与回滚，只有当前进程知道，其他进程是不清楚的。而为了实现多个数据库的事务一致性，就必然需要引入第三方节点来进行事务协调。通过一个全局的分布式事务协调工具，来实现多个数据库事务的提交和回
滚，在这样的架构下，事务的管理方式就变成了两个步骤。

第一个步骤，开启事务并向各个数据库节点写入事务日志。
第二个步骤，根据第一个步骤中各个节点的执行结果，来决定对事务进行提交或者回滚。

这就是所谓的2PC提交协议
在这里插入图片描述
2PC提交流程

表决阶段：此时 TM（协调者）向所有的参与者发送一个事务请求，参与者在收到这请求后，如果准备好了(写事务日志）就会向 TM发送一个执行成功消息作为回应，告知TM 自己已经做好了准备，否则会返回一个失败消息；
提交阶段：TM 收到所有参与者的表决信息，如果所有参与者一致认为可以提交事务，那么 TM就会发送提交消息，否则发送回滚消息；对于参与者而言，如果收到提交消息，就会提交本地事务，否则就会取消本地事务。

三、X/OpenDTP 事务模型（强一致性模型）

X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open这个组织定义的一套分布式事务的标准，也就是定义了规范和API接口，由各个厂商进行具体的实现。

X/Open了定义了规范和API接口，由这个厂商进行具体的实现，这个标准提出了使用二阶段提交(2PC – Two-Phase-Commit)来保证分布式事务的完整性，如下图所示
在这里插入图片描述

X/Open DTP模型定义了三个角色和两个协议：

其中三个角色分别如下：

AP（Application Program）应用程序
RM（Resource Manager）数据库
TM（Transaction Manager）表示事务管理器

两个协议分别是：

XA协议是资源管理器和事务管理器之间的接口规范，目前Oracle、Mysql、DB2都提供了对XA的支持，从而能够实现跨数据库事务。
TX协议：全局事务管理器与资源管理器之间通信的接口。

主流事务框架

Atomikos,Atomikos是为Java平台提供的开源的事务管理工具，它包含收费和开源两个版本，开源版本基本能满足我们的需求。
Bitronix，是一个流行的开源JTA事务管理器实现，你可以使用spring-boot-starterjta-bitronixstarter为项目添加合适的Birtronix依赖。Bitronix
Seata事务，阿里巴巴开源的事务解决方案

四、CAP理论和Base理论

4.1、CAP理论

所谓CAP理论，说的是在分布式架构下的数据一致性问题和性能问题的平衡方案，

C：Consistency 一致性：同一数据的多个副本是否实时相同。
A：Availability 可用性：一定时间内系统返回一个明确的结果则称为该系统可用。
P：Partition tolerance 分区容错性：将同一服务分布在多个系统中，从而保证某一个系统宕机，仍然有其他系统提供相同的服务

CAP理论告诉我们，在分布式系统中，C、A、P三个条件中我们最多只能选择两个。那么问题来了，究竟选择哪两个条件较为合适呢？

对于一个业务系统来说，可用性和分区容错性是必须要满足的两个条件，并且这两者是相辅相成的。业务系统之所以使用分布式系统，主要原因有两个：

提升整体性能，当业务量猛增，单个服务器已经无法满足我们的业务需求的时候，就需要使用分布式系统（集群），使用多个节点提供相同的功能，从而整体上提升系统的性能。
实现分区容错性，单一节点或多个节点处于相同的网络环境下，那么会存在一定的风险，万一该机房断电、该地区发生自然灾害，那么业务系统就全面瘫痪了。为了防止这一问题，采用分布式系统，将多个子系统分布在不同的地域、不同的机房中，从而保证系统高可用性。

这说明分区容错性是分布式系统的根本，此外，可用性对业务系统也尤为重要。在大谈用户体验的今天，如果业务系统时常出现“系统异常”、响应时间过长等情况，这会使得用户流失。在互联网行业竞争激烈的今天，相同领域的竞争者不甚枚举，系统的间歇性不可用会立马导致用户流向竞争对手。因此，我们只能通过牺牲一致性来换取系统的可用性和分区容错。

所以这才有了Zookeeper中的基于少数服从多数的2pc落地方案。因此，也引出了另外一个理论，叫Base理论。

4.2、Base理论

CAP理论告诉我们一个悲惨但不得不接受的事实——我们只能在C、A、P中选择两个条件。而对于业务系统而言，我们往往选择牺牲一致性来换取系统的可用性和分区容错性。不过这里要指出的是，所谓的“牺牲一致性”并不是完全放弃数据一致性，而是牺牲强一致性换取弱一致性的