分布式数据库CAP理论
传统数据库与NoSQL数据库
传统的关系型数据库在功能支持上通常很宽泛，从简单的键值查询，到复杂的多表联合查询再到事务机制的支持。而与之不同的是，NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的体现）。
传统的SQL数据库的事务通常都是支持ACID的强事务机制。A代表原子性，即在事务中执行多个操作是原子性的，要么事务中的操作全部执行，要么一个都不执行;C代表一致性，即保证进行事务的过程中整个数据加的状态是一致的，不会出现数据花掉的情况;I代表隔离性，即两个事务不会相互影响，覆盖彼此数据等;D表示持久化，即事务一但完成，那么数据应该是被写到安全的，持久化存储的设备上（比如磁盘）。
NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，在实际执行的时候是会串行的执行，保证了每一个Key-Value对不会被破坏。例如MongoDB数据库，它是不支持事务机制的，同时也不提倡多表关联的复杂模式设计，它只保证对单个文档(相当于关系数据库中的记录)读写的原子性。
CAP理论
CAP指的是Consistency(强一致性)、Availability(可用性)、Partition tolerance(分区容错性)。
强一致性：系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。 等同于所有节点访问同一份最新的数据副本。
可用性：每一个操作总是能够在一定的时间内返回结果，这里需要注意的是”一定时间内”和”返回结果”。一定时间指的是，在可以容忍的范围内返回结果，结果可以是成功或者失败。
分区容错性：指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信）分离的系统也能够正常运行。理解为在存在网络分区的情况下，仍然可以接受请求。节点crash或者网络分片都不应该导致一个分布式系统停止服务。
CAP既适用于NoSQL数据库，也适用于关系型数据库。它是NoSQL数据库、关系型数据库，乃至一切分布式系统在设计数据多个副本之间读写一致性问题时需要遵循的共同原则。
经典CAP图
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个要求，最多只能同时较好的满足其中的两个。
CAP的证明很简单，假设两个节点集{G1, G2}，由于网络分片导致G1和G2之间所有的通讯都断开了，如果在G1中写，在G2中读刚写的数据， G2中返回的值不可能G1中的写值。由于A的要求，G2一定要返回这次读请求，由于P的存在，导致C一定是不可满足的。
放弃P：如果想避免分区容错性问题的发生，一种做法是将所有的数据（与事务相关的）都放在一台机器上。虽然无法100%保证系统不会出错，但不会碰到由分区带来的负面效果。当然这个选择会严重的影响系统的扩展性。
放弃A:使用网络分区，等数据一致后再去取数据，因此在等待期间系统无法对外提供服务，失去可用性。
放弃C：这里所说的放弃一致性，并不是完全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。以网络购物为例，对只剩下一件库存的商品，如果同时接受到了两份订单，那么较晚的订单将被告知商品告罄。
因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类：
- CA-单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强。
- CP-满足一致性，分区容错的系统，通常可用性不是特别高
- AP-满足可用性，分区容错性的系统，通常可能对一致性要求低。
根据CAP理论，在分布式存储系统中最多只能实现上面的两点，而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
- CA：传统Oracle、mysql数据库
- AP：Tokyo Cabinet、SimpleDB、couchDB、Riak
CP：redis、mongodb
关于BASE
随着时代的发展可以发现，关系数据库的很多特性往往没有用武之地。很多web实时系统并不需要严格的数据库事务，对读的一致性要求很低。有些场合对写一致性要求也并不高。允许实现最终一致性。
很多web应用对数据库的实时性要求也不高。比如说发一条消息之后，过几秒甚至十几秒之后。订阅者才看到这条动态是完全可以接受的。因此牺牲一致性换取可用性，这是目前分布式数据库产品的一种方向。
BASE就是为了解决关系型数据库强一致性引起的可用性降低而提出的解决方案。ACID是关系数据库中的事务的四个性质，在NoSQL数据库中BASE(碱)和ACID(酸)是对应关系。
BASE其实就是下面三个术语的缩写：
- 基本可用（Basically Available）
- 软状态（Soft state）
- 最终一致（Eventually consistent）
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上的改观。
解决CAP
根据一些专家的分析，CAP并不是一个严谨的定律，并不是牺牲了Consistency，就一定能同时获得Availability和Partition Tolerance。还有一个很重要的因素是Latency，在CAP中并没有体现。在现在NoSQL以及其他一些大规模设计时，A和P并不是牺牲C或部分牺牲C的借口，因为即使牺牲了C，也不一定A和P，并且C不一定必须要牺牲。
淘宝一天就处理了1亿零580万，而12306一天处理的交易仅仅166万条 ，如果从并发性上来说，淘宝的并发量远比12306大，但天猫的商品信息，促销数据都可以做缓存，做CDN，而12306的“商品”是一个个座位，这些座位必须通过后端数据库即时查询出来，状态的一致性要求很高。
从这点上看，12306的商品信息很难利用到缓存，因此12306查看“商品”的代价是比较大的，涉及到一系列的后端数据库操作，从这个角度讲，12306的复杂度是高于天猫的。 淘宝的商品相对独立，而12306商品之间的关联性很大，由于CAP定律限制，如果其商品的一致性要求过高，必然对可用性和分区容错性造成影响。
因此，业务设计上，如果找到一条降低一致性要求时，还能保证业务的正确性的业务分拆之路。举个例子，火车票查询时，不要显示多少张，而是显示“有”或“无”，或者显示>100张，50~100,小于50等，这样就可以减小状态的更新频率，充分使用缓存数据。
CAP 理论说在一个系统中对某个数据不存在一个算法同时满足 Consistency, Availability, Partition-tolerance。注意，这里边最重要和最容易被人忽视的是限定词“对某个数据不存在一个算法”。这就是说在一个系统中，可以对某些数据做到 CP, 对另一些数据做到 AP，就算是对同一个数据，调用者可以指定不同的算法，某些算法可以做到 CP，某些算法可以做到 AP。
最后
虽然设计师仍然需要在分区的前提下对数据一致性和可用性做取舍，但具体如何处理分区和恢复一致性，这里面有不计其数的变通方案和灵活度。当代CAP实践应将目标定为针对具体的应用，在合理范围内最大化数据一致性和可用性的“合力”。这样的思路延伸为如何规划分区期间的操作和分区之后的恢复，从而启发设计师加深对CAP的认识，突破由于CAP理论的表述而产生的思维局限。
分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过RPC/RMI之间通信和调用，对外提供服务和组内协作。
集群：不同的多台服务器上面部署相同的模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。