网络编程中的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各项指标虽然没有提升，但好处是：

1. 单个服务器宕机只会导致服务降级；
2. 集群有了扩容缩容的可能性，这就叫做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也有碱的意思。

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