CAP理论

CAP理论指的是分布式系统中不可能同时满足以下三种条件:

这里的分布式系统指的是各节点互通并且共享数据, 如果各节点存储的数据均不同则不满足该理论, 如memcached集群

在分布式系统中, 分布也暗示了分区容错的存在, 所以当网络异常时, 一般只从一致性和可用性上进行选择:

CA相当于是非分布式

如下图:

注意: CAP指的是在网络异常时才需要进行一致性和可用性的选择, 当网络无异常时, 两者都可以满足.

ACID

ACID(Atomicity, Consistency, Isolation, Durability)是数据库事务的四个属性, 用来保证事务操作的有效性(即使在极端条件下如网络异常, 机器故障等). 在数据库中, 满足ACID的一系列数据库操作称为事务. ACID的详细描述如下:

Atomicity: 原子性, 一个事务通常包括多个语句(Statements), 原子性保证每个事务被当做一个整体来处理, 要么完全成功, 要么完全失败; 如果事务中只有部分语句执行失败, 则整个事务操作失败, 所有的改变被撤销; 比如取钱, 这个事务分为扣款和出钱两个步骤, 要么两个同时成功, 或同时失败, 否则就可能出现扣款了但是钱没出来的情况
Consistency: 一致性, 指在事务执行中写入的数据仍然满足数据库中定义的约束条件, 如constraints, cascades, triggers等。如数据库中定义了约束了a+b=10，一个事务只改变了a, 则该事务会失败回滚
Isolation: 隔离性, 指事务在并发执行时, 不会出现交错执行的情况, 只会一个接一个执行, 否则可能会导致数据不一致. 如有两个事务A和B均是对数据T(值为0)进行操作, 并都有加10和减10两个步骤的操作, 当A执行完第一个步骤后, B接着执行完两个步骤, 然后A执行第二个步骤失败, 最终数据T的结果会10, 而实际应该是0, 这就产生了不一致
Durability: 持久性, 指事务处理结束后, 对数据的修改就是永久的, 即便系统故障也不会丢失. 事务的数据的写入只有在写入到non-volatile memory(如磁盘)才算完成, 否则可能出现故障导致数据丢失

MySQL的Innodb是通过redo log来保证持久性

BASE((Basically Available, Soft state, Eventual consistency))指得是基本可用,软状态和最终一致性. 详细描述如下:

Basically Available: 基本可用, 指尽可能保证基础的读写(basic reading and writing)操作, 但是不保证数据的一致性(写操作可能会无法保存, 读操作可能会拿到旧数据)
Soft state: 软状态, 指系统的状态可能会一直变, 即使在没有输入的情况, 因为数据可能还在同步(最终一致性)
Eventually consistent: 最终一致性, 指正常运行的系统在无新的输入的情况下, 经过一段时间后, 所有的副本节点的数据会达到一致

BASE关注的是可用性和分区容错, 所以CAP中的AP类.

一致性模型是分布式系统中不同节点间数据的同步管理模型, 包括严格一致性, 顺序一致性和强一致性模型等, 这里介绍仅介绍常用的三种:

强一致性模型: 写请求要等到数据写入所有的节点数据后才返回, 从而保证所有节点数据都一致, 缺点是会带来高延迟
弱一致性模型: 不保证读请求获取的数据是最新的
最终一致性模型: 是弱一致性模型的一种特殊情况, 不保证读请求获取的数据是最新的, 但在无新的输入的情况下, 经过一段时间后, 所有的副本节点的数据会达到一致