CAP
CAP理论最早是在2000年7月19号，由Berkeley的Eric Brewer教授在ACM PODC会议上的一个开题演讲中提出，PPT在此。此后，MIT的Seth Gilbert和Nancy Lynch，理论上证明了Brewer猜想是正确的，CAP理论在学术上正式作为一个定理出现了。
CAP理论的C就是一致性（Consistency），这里不多解释，想了解的可以看看我之前写过的一致性的一些东西；A就是可用性（availability），可以理解为是否可获取数据，以及获取数据的速度；P就是分区容忍度（partion tolerance），指的是系统中的数据分布性的大小对系统的正确性，性能的影响（一定程度上就是可扩展性）。这个理论的主要意思就是这三个是不可以同时做到很好的，我们在实现一个分布式系统时（包括分布式数据库），是不可能同时完美的实现三个方面。其实这个理论可以用“鱼和熊掌不可兼得”一言以蔽之。
NoSQL一定程度上就是基于这个理论提出来的，因为传统的SQL数据库（关系型数据库）都是都是具有ACID属性，对一致性要求很高，因此降低了A（availability）和P（partion tolerance），因此，为了提高系统性能和可扩展性，必须牺牲C（consistency），推翻关系型数据库中ACID这一套。
依据CAP理论，从应用的需求不同，我们对数据库（其实就是一种结构化数据存储，和Bolb恰好不同）时，可以从三方面考虑：
- 考虑CA，这就是传统上的关系型数据库(RMDB).
- 考虑CP，主要是一些Key-value数据库，典型代表为google的Big Table
- 考虑AP，主要是一些面向文档的适用于分布式系统的数据库，如SimpleDB。
而对大型网站尤其是SNS网站，对于数据的短期存储，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，而对于数据的持久存储，可以通过传统的SQL来保证一致性（最终一致性）。
CAP理论出现后，很多大规模的网站，尤其是SNS网站的数据库设计都利用其思想，包括Amazon,Facebook和Twitter这几个新兴的IT巨头，因此，一定程度上来讲，他们都是CAP的信徒。另一方面，他们从实践上证明了CAP理论的正确性。
最终一致性
- 存储系统
存储系统可以理解为一个黑盒子，它为我们提供了可用性和持久性的保证。
- Process A
ProcessA主要实现从存储系统write和read操作
- Process B 和ProcessC
ProcessB和C是独立于A，并且B和C也相互独立的，它们同时也实现对存储系统的write和read操作。
下面以上面的场景来描述下不同程度的一致性：
- 强一致性
强一致性（即时一致性） 假如A先写入了一个值到存储系统，存储系统保证后续A,B,C的读取操作都将返回最新值
- 弱一致性
假如A先写入了一个值到存储系统，存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念，它特指从A写入值，到后续操作A,B,C读取到最新值这一段时间。
- 最终一致性
最终一致性是弱一致性的一种特例。假如A首先write了一个值到存储系统，存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话，最终所有的读取操作都会读取到最A写入的最新值。此种情况下，如果没有失败发生的话，“不一致性窗口”的大小依赖于以下的几个因素：交互延迟，系统的负载，以及复制技术中replica的个数（这个可以理解为master/salve模式中，salve的个数），最终一致性方面最出名的系统可以说是DNS系统，当更新一个域名的IP以后，根据配置策略以及缓存控制策略的不同，最终所有的客户都会看到最新的值。
变体
- Causal consistency（因果一致性）
如果Process A通知Process B它已经更新了数据，那么Process B的后续读取操作则读取A写入的最新值，而与A没有因果关系的C则可以最终一致性。
- Read-your-writes consistency
如果Process A写入了最新的值，那么Process A的后续操作都会读取到最新值。但是其它用户可能要过一会才可以看到。
- Session consistency
此种一致性要求客户端和存储系统交互的整个会话阶段保证Read-your-writes consistency.Hibernate的session提供的一致性保证就属于此种一致性。
- Monotonic read consistency
此种一致性要求如果Process A已经读取了对象的某个值，那么后续操作将不会读取到更早的值。
- Monotonic write consistency
此种一致性保证系统会序列化执行一个Process中的所有写操作。
BASE
说起来很有趣，BASE的英文意义是碱，而ACID是酸。真的是水火不容啊。
- Basically Availble --基本可用
- Soft-state --软状态/柔性 事务
"Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
- Eventual Consistency --最终一致性
最终一致性， 也是是 ACID 的最终目的。
BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片
BASE思想主要强调基本的可用性，如果你需要高可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。
从CAP原理讲起，然后将目前的各大 NoSQL 产品进行了分类，如下：
按功能分类：
- Relational 关系性数据库，这里就不多说了，像我们常用的 MySQL 就是杰了代表。
- Key-value 键值存储，支持简单的get ，set，delete等协议。
- Column-oriented 列式存储，通常不支持join操作，与传统关系型数据库的行式存储相比他的存储是列式的，这样会让很多统计聚合操作更简单方便。
- Document-oriented 文档型存储，通常是将数据存在Json或者Xml，同样不支持join操作。这种存储方式可以很容易地被面向对象的语言所使用。
满足一致性，可用性的系统，通常在可扩展性上不太强大：
- Traditional RDBMSs like Postgres, MySQL, etc (relational)
- Vertica (column-oriented)
- Aster Data (relational)
- Greenplum (relational)
满足一致性，分区容忍性的系统，通常性能不是特别高:
- BigTable (column-oriented/tabular)
- Hypertable (column-oriented/tabular)
- HBase (column-oriented/tabular)
- MongoDB (document-oriented)
- Terrastore (document-oriented)
- Redis (key-value)
- Scalaris (key-value)
- MemcacheDB (key-value)
- Berkeley DB (key-value)
满足可用性，分区容忍性的系统，通常可能对一致性要求低一些:
- Dynamo (key-value)
- Voldemort (key-value)
- Tokyo Cabinet (key-value)
- KAI (key-value)
- Cassandra (column-oriented/tabular)
- CouchDB (document-oriented)
- SimpleDB (document-oriented)
- Riak (document-oriented)
