数据库ACID和CAP原则

原創

2020-06-21 15:53

1 单机场景

单台物理机（服务器、主机）中的关系型数据库遵循ACID原则，对应关系如下表：

序号	原则	描述
1	原子性（Atomicity）	事务所有操作要么全部完成，要么全部不完成，一荣俱荣，一损俱损
2	一致性（Consistency）	事务开始或结束时，数据库状态一致（中间状态的数据对外不可见，只有最初状态和最终状态的数据对外可见），保证操作前和操作后数据结构一致，监控数据的中间状态，若有错误，则立即回滚
3	隔离性（Isolation）	多个事务操作，互不干扰，事务锁保证事务的隔离，可能会出现死锁
4	持久性（Durability）	事务完成之后，无法回滚

一致性在前，原子性在后，事务进行时，首先由一致性监控操作过程中数据是否一致，若数据结构发生变化，则进行回滚，这时原子性保证了数据回滚到初始状态。

2 分布式场景

分布式场景，数据分布在多台物理机（服务器、主机）中，数据库遵循CAP原则，对应关系如下表：

序号	原则	描述
1	一致性（Consistency）	数据一致更新，所有机器数据的变动同步进行
2	可用性（Availability）	高可用性，多台物理机集群中部分机器故障，其余部分物理机是否能正常响应客户端读写请求
3	分区容错性（Partition tolerance）	分区为网络分区（如上海和北京的网络区），容错性只多台物理机容忍网络通信故障的能力，多台物理机间通信不能在时限内达成数据一致，说明物理机通讯异常（出现网络分区），必须在C和A之间进行选择

序号	放弃	描述
1	C	放弃实时一致性，即数据的一致性时间变长，部分物理机数据先变化，其余物理机一段时间后变化，但最终多台物理机数据是一致的
2	A	放弃高可用，任一单台物理机发生故障，整体物理机集群全部不对外提供数据读写服务
3	P	放弃分区容错性，当网络分区异常时无法保证多台物理机数据的一致

序号	方案	数据库	说明
1	CA	RDBMS	保证数据强一致性和高可用性，但网络分区故障时，数据服务不可用
2	CP	MongoDB、HBase、Redis	保证数据强一致性和网络故障容灾，但，任意物理机故障时，数据不可用
3	AP	CouchDB、Cassandra、DynamoDB、Riak	保证数据网络故障可用和物理机故障容灾，但牺牲数据实时一致性

BASE理论是权衡强一致性和高可用的结果，介绍如下表：

序号	属性	描述
1	基本可用（Basically Available）	系统出现了不可预知个故障，但是仍可用，此时响应速度变慢、功能缩水，但可正常工作
2	软状态（Soft State）	允许物理机数据存在中间状态，允许多物理机数据时延
3	最终一致性（Eventually Consistent）	多物理机中的数据一致存在时间间隔，但时延期之后，物理机集群数据完全一致

理论上分布式过程中不存在同时满足CAP三个特性的分布式集群；
BASE理论对CAP中一致性和可用性的权衡，即使无法做到强一致性，但每个应用可以根据自身业务特点，采用适当的方式使系统达到最终一致性；
不同的场景需要不同的搭配方案，如CA，CP，AP；
对于机器数量庞大，时常出现网络故障，可用性是必要的，因此使用AP，对于数据强一致的场景（如银行、证券）需要权衡CA和CP，当网络故障时，CA原则的数据完全不可用，CP原则部分可用；当机器部分故障时，CA原则数据可用，CP原则的数据完全不可用；

發表評論

所有評論

還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.