CAP
C：consistency，数据在多个副本中能保持一致的状态。
A：Availability，整个系统在任何时刻都能提供可用的服务，通常达到99.99%四个九可以称为高可用
P：Partition tolerance，分区容错性，在分布式中，由于网络的原因无法避免有时候出现数据不一致的情况，系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择，换句话说，系统可以跨网络分区线性的伸缩和扩展。
CAP理论的核心：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。
- CA：单点集群，满足一致性，可用性的系统，通常在可扩展上不太强大。应用：传统的Oracle数据库
- CP：满足一致性，分区容错性的系统，通常性能不是特别高。应用：Redis，MongoDB，银行
- AP：满足可用性，分区容错性，通常可能对一致性要求低一些。应用：大多数网站架构的选择
CAP理论就是说在分布式存储系统中，最多只能实现其二。
而由于当前的网络硬件肯定会出现延迟丢包等问题。所以分区容忍性是我们必须需要实现的
所以我们只能在一致性和高可用之间进行权衡，没有NoSQL系统能同时保证三点。
分布式和集群
分布式：不同的多台服务器上面部署不同的服务模块（工程）
集群：不同的多台服务器上面部署相同的服务模块。通过分布式调度软件进行统一的调度，对外提供服务和访问。
Base理论
Base就是为了解决关系型数据库强一致性引起的问题而导致的可用性降低而提出的解决方案。
Base其实是下面三个术语的缩写：
- 基本可用（Basically Available）
- 软状态（Soft state）状态可以有一段时间不同步
- 最终一致（Eventually consistent）最终数据是一致的就可以了，而不是时时保持强一致
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。
为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法。
以案例转账为例：
我们把用户A给用户B转账分成四个阶段，第一个阶段用户A准备转账，第二个阶段从用户A账户扣减余额，第三个阶段对用户B增加余额，第四个阶段完成转账。系统需要记录操作过程中每一步骤的状态，一旦系统出现故障，系统能够自动发现没有完成的任务，然后，根据任务所处的状态，继续执行任务，最终完成任务，达到一致的最终状态。
在实际应用中，上面这个过程通常是通过持久化执行任务的状态和环境信息，一旦出现问题，定时任务会捞取未执行完的任务，继续未执行完的任务，直到执行完成为止，或者取消已经完成的部分操作回到原始状态。
这种方法在任务完成每个阶段的时候，都要更新数据库中任务的状态，这在大规模高并发系统中不会有太好的性能，一个更好的办法是用Write-Ahead Log（写前日志），这和数据库的Bin Log（操作日志）相似，在做每一个操作步骤，都先写入日志，如果操作遇到问题而停止的时候，可以读取日志按照步骤进行恢复，并且继续执行未完成的工作，最后达到一致。写前日志可以利用机械硬盘的追加写而达到较好性能，因此，这是一种专业化的实现方式。
但是多数业务系统还是使用数据库记录的字段来记录任务的执行状态，也就是记录中间的“软状态”，一个任务的状态流转一般可以通过数据库的行级锁来实现，这比使用Write-Ahead Log实现更简单、更快速。