从`ACID`到`CAP`到`BASE`

2016/3/2 posted in  数据库

ACID

  1. Atomic原子性

事务必须是一个原子的操作序列单元,事务中包含的各项操作在一次执行过程中,要么全部执行成功,要么全部不执行,任何一项失败,整个事务回滚,只有全部都执行成功,整个事务才算成功。

  1. Consistency一致性

事务的执行不能破坏数据库数据的完整性和一致性,事务在执行之前和之后,数据库都必须处于一致性的状态

  1. Isolation隔离性

在并发环境中,并发的事务是相互隔离的,一个事务的执行不能被其他事务干扰。

  1. Durability持久性

一个事务一旦提交,它对数据库中对应数据的状态变更就应该是永久性的,即使发生系统崩溃或机器宕机,只要数据库能够重新启动,那么一定能够将其恢复到事务成功结束时的状态。

SQL中的4个事务隔离级别

  • 读未提交:允许脏读。如果一个事务正在处理某一数据,并对其进行了更新,但同时尚未完成事务,因此事务没有提交。
  • 读已提交:允许不可重复读。只允许读到已经提交的数据。
  • 可重复读:允许幻读。即同样的事务操作,在前后两个时间段内执行对同一个数据项的读取,可能出现不一致的结果。
  • 串行化:最严格的事务,要求所有事务被串行执行,不能并发执行。

CAP定理

一个分布式系统不可能同时满足一致性Consistency、可用性Availability、分区容错性Partition tolerance这三个基本需求,最多只能同时满足其中的两项。

一致性

分布式环境中,一致性是指多个副本之间能否保持一致的特征。在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处理一致的状态。

可用性

系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回正常结果

分区容错性

分布式系统在遇到任何网络分区故障时,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障。

BASE定理

Basically Available(基本可用)、Soft State(软状态)、Eventually Consistent(最终一致性),基于CAP定理演化而来,核心思想是即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。

Basically Available(基本可用)

分布式系统在出现不可预知的故障的时候,允许损失部分可用性,但不等于系统不可用。

Soft State(软状态)

允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

Eventually Consistent(最终一致性)

强调系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。