网络编程中的CAP & 有趣的存储框架（关系型、NoSQL）全图

第七篇 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也有碱的意思。

最后来一张存储框架的全家福：