（二）、分布式数据库中CAP原理+BASE

1. 传统的数据库中的ACID分别是什么：

• A（Atomicity）原子性
  原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚

• C（Consistency）一致性
  一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束

• I（Isolation）独立性
  所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响

• D（Durability）持久性
  持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失

2. NoSQL数据库中CAP分别是什么：

C：Consistency（强一致性）
A：Availability（可用性）
P：Partition tolerance（分区容错性）

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个
因此，根据CAP原理将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大
CP - 满足一致性，分区容错性的系统，通常性能不是特别高
AP - 满足可用性，分区容错性的系统，通常可能对一致性要求低一些

3. CAP的3进2

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点，而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点
C：（强一致性） A：（可用性） P：（分区容错性）
CA：传统Oracle数据库
AP：大多数网站架构的选择
CP：Redis，Mongodb

4. 一致性与可用性的决择

对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

• 数据库事务一致性需求
  很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高，允许实现最终一致性
• 数据库的写实时性和读实时性需求
  对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很低web应用来说，并不要求这么高的实时性，比方说发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的
• 对复杂的SQL查询，特别是多表关联查询的需求
  任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生，往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了

5. BASE是什么？

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案
BASE其实是下面三个术语的缩写：
基本可用（Basically Available）
软状态（Soft state）
最终一致（Eventually consistent）
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观，为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法

举例说明CP和BASE：
像淘宝双十一，当天数据量极大，比如说一件商品，关注点在于多少人买了这件商品，并不是多少人浏览了，这时候肯定是用到了AP，但是双十一过后，要把每一件商品的浏览量大概统计出来，这时候就用到了BASE，牺牲了A，满足了C
各大技术爱好者们，不知道整理的有没有问题，如果本篇文章那块有问题，欢迎留言!