第七篇 CAP
https://zhuanlan.zhihu.com/p/20399316?refer=auxten
CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：
- 一致性 (Consistency)（等同于所有节点访问同一份最新的数据副本）
- 可用性（Availability）（对数据更新具备高可用性）
- 网络分区容忍性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）
- （上面的解释不好，看这个）系统中有部分服务或模块挂掉或失效的时候，不影响系统正常服务。分区容忍性：分布式系统在遇到任何网络分区故障的时候，仍然能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。
理解CAP理论的最简单方式是想象两个节点分处分区两侧。 允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。 如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。 除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。
CAP原理实例推导
单实例
所有单机版的系统都属于这个范畴，例如MySQL、memcached、redis。
Sharding
由于数据库之间没有互相通信，并不依赖彼此的存在，所以分区可容忍性依旧没有破坏。
这种情况下CAP各项指标虽然没有提升，但好处是：
- 单个服务器宕机只会导致服务降级；
- 集群有了扩容缩容的可能性，这就叫做scalability。
这种分布式的方式常用于：
- 分布式memcached、redis
- 传统的数据库Sharding
- BigTable (列存储式数据库)
- Hypertable (列存储式数据库)
- HBase (列存储式数据库)
- MongoDB (文档式数据库)
- Terrastore (文档式数据库)
- Redis (KV数据库)
- Scalaris (KV数据库)
- MemcacheDB (KV数据库)
- Berkeley DB (KV数据库)
多副本写入
Clustering
多副本模式：
由于上述方案是强一致性( C )的，这种应用场景常见于金融系统，这种这方面典型的代表有：
- ZooKeeper (KV数据库)
- Vertica (列存储式数据库)
- Aster Data (关系型数据库)
- Greenplum (关系型数据库)
由于大多数互联网公司的需求不是要求强一致性( C )， 所以通过放弃一致性，达到更高的可用性( A )和分区可容忍性 ( P )成了目前市面上大多数NoSQL数据库的核心思想。
这方面典型的代表还有：
- Dynamo (KV数据库)
- Voldemort (KV数据库)
- Tokyo Cabinet (KV数据库)
- KAI (KV数据库)
- Cassandra (列存储式数据库)
- CouchDB (文档式数据库)
- SimpleDB (文档式数据库)
- Riak (文档式数据库)
- MooseFS (类GFS分布式文件系统)
有没有可能将CAP同时提升呢？答案是：Sure, ofcourse.
我们可以通过用更高可靠性的服务器、更可靠的网络设备达到CAP同时提升。
但注意，只是提升，不是完全解决。
BASE & ACID
数据库的事务有ACID的保证。
后来，随着NoSQL的兴起，技术界又提出了BASE的概念：
-
Basically Availble --基本可用
支持分区失败（Sharding碎片划分数据库），出了问题服务仅降级（部分不可用）。
-
Soft-state --软状态/柔性
事务"Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的。 软状态就是可以有一段时间不同步，异步。
-
Eventual Consistency --最终一致性
最终数据是一致的就可以了，而不是时时一致。
合起来就是BASE。
比较有意思的是：在英语里ACID是酸的意思；BASE也有碱的意思。
最后来一张存储框架的全家福：
