Nosql数据库中CAP原理CAP+BASE
关系型数据库严格遵循ACID理论。但当数据库要开始满足横向扩展、高可用、模式自由等需求时，需要对ACID理论进行取舍，不能严格遵循ACID。以CAP理论和BASE理论为基础的NoSQL数据库开始出现。
1.在我们传统数据库中的ACID分别是
原子性（Atomicity），一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有被执行过一样。
一致性（Consistency），在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作
独立性（Isolation），数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
持久性（Durability），事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
2.而在NoSql数据库中强调的CAP是
强一致性（Consistency），可用性（Availability），分区容错性（Partition tolerance）
一般来说关系型数据库中ACID四个都要满足，但是CAP我们只能三选二
因此，根据CAP原理将NoSQL数据库分成满足CA，CP，AP原则的三大类
CA：单点集群，满足一致性，可用性的系统，通常再可扩展性上不太强大（例如，传统的Oracle数据库）
CP：满足一致性，而P（分区）会导致同步时间无限延长，通常性能不是特别高 （Redis，MongoDB）
AP：满足可用性，分区容忍性的系统，通常对一致性要求低一些，大多数网站架构的选择
CAP理论就是说再分布式存储系统中，最多只能实现上面两点。
由于当前网络硬件肯定会出现延迟丢包等问题，
所以，分区容忍性是我们必须要实现的
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证三点
3.一致性和可用性的抉择
对于web2.0的网站来说，关系型数据库的很多主要特性却无用武之地
数据库事务一致性需求
很多web实时系统并不要求雅阁的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高 。允许实现最终一致性。
数据库的写实时性和读实时性的需求
对系统数据库来说，插入一条数据之后立刻查询，是肯定可以独处这条数据。但是对于大多数web应用来说，并不要求这么高的实时性，当我们发布一条消息后，过上几秒或是几十秒后被接受看到都是被允许的（如发微博/直播等，都是具有延迟的）
对付在的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询。我们吧这些数据进行整合以k-v键值对的形式放到缓存里面，避免了数据库查询，这样子记得到我们所要的内容，又不给数据库增加负担，这样增强了数据的高可用。往往更多是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被弱化
4什么是BASE
BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案
BASE是由下面三个术语缩写成
基本可用（Basically Available）：基本可用。这里是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心功能或者当前最重要功能可用。对于用户来说，他们当前最关注的功能或者最常用的功能的可用性将会获得保证，但是其他功能会被削弱。
软状态（Soft state）：允许系统数据存在中间状态，但不会影响到系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步时存在延时。
最终一致（Eventually consistent）：要求系统数据副本最终能够一致，而不需要实时保证数据副本一致。最终一致性是弱一致性的一种特殊情况。最终一致性有5个变种：因果一致性，读己之所写（例如发微博的时候，自己可以马上看到，但是粉丝要过几秒钟），绘画一致性，单调读一致性，单调写一致性
他的思想就是通过让系统在某一时刻牺牲数据一致性的要求来换取系统整体的伸缩性和性能上的改观。（也就是说牺牲C 来实现AP，以BASE的理论来达成最终一致性）。
原因就是，大型系统由于地域分布和极高的性能要求，不可能采用分布式事务来完成这些指标，要想完成，就要采用另一种方式来完成，BASE就是解决该问题的方法