数据库分类与数据库基本原则（ACID、CAP、BASE）

分布式系统中ACID和CAP有什么区别 - 知乎 (zhihu.com)

关系型数据库遵循ACID规则 && NoSQL 数据库BASE CAP - 玲汐 - 博客园 (cnblogs.com)

分布式系统设计时，遵循CAP原则_alpha_2017的博客-CSDN博客

1、数据库与数据库规则

1.1 数据库

1）关系型数据库SQL：

​ 传统的SQL数据库的事务通常都是支持ACID的强事务机制

• 关系型数据库：

  - 高度组织化结构化数据
  - 结构化查询语言（SQL） (SQL)
  - 数据和关系都存储在单独的表中。
  - 数据操纵语言，数据定义语言
  - 严格的一致性
  - 基础事务

2）非关系型数据库NoSQL：

​ NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的体现）。NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，在实际执行的时候是会串行的执行，保证了每一个Key-Value对不会被破坏。

• NoSQL的优点/缺点

  优点:

  • - 高可扩展性
  • - 分布式计算
  • - 低成本
  • - 架构的灵活性，半结构化数据
  • - 没有复杂的关系

  缺点:

  • - 没有标准化
  • - 有限的查询功能（到目前为止）
  • - 最终一致是不直观的程序

NoSQL 数据库分类：

类型	部分代表	特点
列存储	Hbase Cassandra Hypertable	顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势。
文档存储	MongoDB CouchDB	文档存储一般用类似json的格式存储，存储的内容是文档型的。这样也就有有机会对某些字段建立索引，实现关系数据库的某些功能。
key-value存储	Tokyo Cabinet / Tyrant Berkeley DB MemcacheDBRedis	可以通过key快速查询到其value。一般来说，存储不管value的格式，照单全收。（Redis包含了其他功能）
图存储	Neo4J FlockDB	图形关系的最佳存储。使用传统关系数据库来解决的话性能低下，而且设计使用不方便。
对象存储	db4o Versant	通过类似面向对象语言的语法操作数据库，通过对象的方式存取数据。
xml数据库	Berkeley DB XML BaseX	高效的存储XML数据，并支持XML的内部查询语法，比如XQuery,Xpath。

3）SQL与NoSQL对比：

对比项	关系型SQL	非关系型SQL
数据存储	关系表	数据集（键值/JSON文档/哈希表/其它）
模式结构	结构化、提前定义表结构	动态调整模式，非结构化
扩展方式	纵向扩展，提高处理能力	横向扩展、增加分布式节点
数据查询	标准通用的查询语言SQL	非标准非结构化的查询语言（unQL）
关键特性	ACID	CAP、BASE
主要优势	结构化、事务处理、易于维护使用	扩展性、灵活调整、大数据分析
主要劣势	扩展性、高并发场景、大数据分析	事务支持较弱、标准不统一

1.2 ACID——数据库规则（数据库事务正确执行的四要素、事务的四个特征）

ACID：是指数据库管理系统（DBMS）在写入或更新资料的过程中，为保证事务（transaction）是正确可靠的，所必须具备的四个特性：原子性（atomicity，或称不可分割性）、一致性（consistency）、隔离性（isolation，又称独立性）、持久性（durability）。

• ACID 是关系型数据库强烈遵循的事务原则。

​ 事务的定义和实现一直随着数据管理的发展在演进，当计算机越来越强大，它们就能够被用来管理越来越多数据，最终，多个用户可以在一台计算机上共享数据，这就导致了一个问题，当一个用户修改了数据而另外一个还在使用旧数据进行计算过程中，这里就需要一些机制来保证这种情况不会发生。

ACID规则原来是在1970被Jim Gray定义，ACID事务解决了很多问题，但是仍然需要和性能做平衡协调，事务越强，性能可能越低，安全可靠性和高性能是一对矛盾。

一个事务是指对数据库状态进行改变的一系列操作变成一个单个序列逻辑元操作，数据库一般在启动时会提供事务机制，包括事务启动 停止 取消或回滚。

但是上述事务机制并不真的实现“事务”，一个真正事务应该遵循ACID属性，ACID事务才真正解决事务，包括并发用户访问同一个数据表记录的头疼问题。

ACID的定义：

• Atomic原子性: 一个事务的所有系列操作步骤被看成是一个动作，所有的步骤要么全部完成要么一个也不会完成，如果事务过程中任何一点失败，将要被改变的数据库记录就不会被真正被改变。
• Consistent一致性: 数据库的约束 级联和触发机制Trigger都必须满足事务的一致性。也就是说，通过各种途径包括外键约束等任何写入数据库的数据都是有效的，不能发生表与表之间存在外键约束，但是有数据却违背这种约束性。所有改变数据库数据的动作事务必须完成，没有事务会创建一个无效数据状态，这是不同于CAP理论的一致性"consistency".
• Isolated隔离性: 主要用于实现并发控制, 隔离能够确保并发执行的事务能够顺序一个接一个执行，通过隔离，一个未完成事务不会影响另外一个未完成事务。
• Durable持久性: 一旦一个事务被提交，它应该持久保存，不会因为和其他操作冲突而取消这个事务。很多人认为这意味着事务是持久在磁盘上，但是规范没有特别定义这点。

1.3 CAP——分布式系统原则

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

• CAP是分布式系统（数据库）遵循的原则

CAP是分布式系统中进行平衡的理论，它是由 Eric Brewer发布在2000年。

• Consistent一致性: 同样数据在分布式系统中所有地方都是被复制成相同——等同于所有节点都能同步到客户端更新的最新数据
• Available可用性: 所有在分布式系统活跃的节点都能够处理操作且能响应查询——每次请求都能在规定时间内获得响应，但是不保证获取的数据为最新数据
• Partition Tolerant分区容错性: 在两个复制系统之间，如果发生了计划之外的网络连接问题，对于这种情况，有一套容错性设计来保证。——系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

分区容错性：

【即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，或者是机器之间有网络异常，将分布式系统分隔未独立的几个部分，各个部分还能维持分布式系统的运作，这样就具有好的分区容错性。重点是服务器节点之间的通讯中断，而不是与客户之间的中断。server1、server2都能对外提供服务只是两个服务器节点之间无法同步数据。】

一致性：

​ 对于一致性，可以分为从客户端和服务端两个不同的视角。

从客户端来看: 主要指的是多并发访问时更新过的数据如何获取的问题。

从服务端来看: 更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。

​ 从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。

• 对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。——ACID
• 如果能容忍后续的部分或者全部访问不到，则是弱一致性。——CAP
• 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。——BASE

CAP原则三选二的权衡：

一般情况下CAP理论认为你不能同时拥有上述三种，只能同时选择两种，这是一个实践总结，当有网络分区情况下，也就是分布式系统中，你不能又要有完美一致性和100%的可用性，只能这在两者选择一个。在单机系统中，你则需要在一致性和延迟性latency之间权衡。

根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

1. CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。——传统Oracle数据库

   这种情况在分布式系统中几乎是不存在的。首先在分布式环境下，网络分区（通讯故障）是一个自然的事实。因为分区是必然的，所以如果舍弃P，意味着要舍弃分布式系统。
   比如我们熟知的关系型数据库，如My Sql和Oracle就是保证了可用性和数据一致性，但是他并不是个分布式系统。一旦关系型数据库要考虑主备同步、集群部署等就必须要把P也考虑进来。
   

2. CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。——Redis、MongoDB分布式存储

   如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。一个保证了CP而一个舍弃了A的分布式系统，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待服务器数据恢复后才会提供服务。
   
   设计成CP的系统其实也不少，其中最典型的就是很多分布式数据库，他们都是设计成CP的。在发生极端情况时，优先保证数据的强一致性，代价就是舍弃系统的可用性。如Redis、HBase等，还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。
   
   无论是像Redis、HBase这种分布式存储系统，还是像Zookeeper这种分布式协调组件。数据的一致性是他们最最基本的要求。一个连数据一致性都保证不了的分布式存储要他有何用？
   

3. AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。——大多数网站架构的选择

     要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
   
    这种舍弃强一致性而保证系统的分区容错性和可用性的场景和案例非常多。对于很多业务系统来说，比如淘宝的购物，12306的买票。都是在可用性和一致性之间舍弃了一致性而选择可用性。
   
   	你在12306买票的时候肯定遇到过这种场景，当你购买的时候提示你是有票的（但是可能实际已经没票了），你也正常的去输入验证码，下单了。但是过了一会系统提示你下单失败，余票不足。这其实就是先在可用性方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，会影响一些用户体验。
   
   	但是，我们说很多网站牺牲了一致性，选择了可用性，这其实也不准确的。就比如上面的买票的例子，其实舍弃的只是强一致性，退而求其次保证了最终一致性。也就是说，虽然下单的瞬间，关于车票的库存可能存在数据不一致的情况，但是过了一段时间，还是要保证最终一致性的。
   
   

注意：分布式架构的时候必须做出取舍。分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。多余大多数web应用，其实并不需要强一致性。因此牺牲C换取P，这是目前分布式数据库产品的方向。

1.4 BASE——分布式原则，对CAP中一致性和可用性权衡的结果

• BASE原则是对CAP中一致性和可用性权衡的结果

BASE是NoSQL数据库通常对可用性及一致性的弱要求原则:

• 基本可用（Basically Available）
• 软状态（Soft state）： “Soft state” 可以理解为"无连接"的, 而 “Hard state” 是"面向连接"的
• 最终一致（Eventually consistent）：也是是 ACID 的最终目的。

​ BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

​ 它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法

• 基本可用（Basically Available）:

  分布式系统在出现故障时，允许损失 部分可用功能，保证核心功能可用。举例如下：

  **1. 响应时间上的损失（可用，但查询比平时慢）：**正常情况下，搜索引擎会在0.5秒内返回查询结果给用户，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。

  **2. 功能上的损失：**在正常情况下，用户可以在一个电商网站上顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。比如：“数据加载失败，请稍后重试”

• 软状态（Soft state）：

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

• 最终一致性（Eventually consistent）：

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

1.5 对比

CAP和ACID中一致性区别

• ACID一致性是有关数据库规则，如果数据表结构定义一个字段值是唯一的，那么一致性系统将解决所有操作中导致这个字段值非唯一性的情况，如果带有一个外键的一行记录被删除，那么其外键相关记录也应该被删除，这就是ACID一致性意思。

• CAP理论的一致性是保证同样一个数据在所有不同服务器上的拷贝都是相同的，这是一种逻辑保证，而不是物理，因为光速限制，在不同服务器上这种复制是需要时间的，集群通过阻止客户端查看不同节点上还未同步的数据维持逻辑视图。

​

一致性对比：

​ 从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。

• 对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。——ACID
• 如果能容忍后续的部分或者全部访问不到，则是弱一致性。——CAP
• 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。——BASE