CAP定理与分布式数据库管理系统

本文译自:CAP Theorem and Distributed Database Management Systems

早年间提升 数据存储规模 以及 系统处理能力 的手段多为 垂直扩容scale vertically ), 即采用性能更高的服务器,或者优化现有代码。

然而,随着 并行处理parallel processing )以及 分布式系统distributed system )优势日益显现,水平扩容 ( scale horizontally )更加流行,即用更多服务器并行地处理任务。

Apache 项目涌现了大量数据处理工具,包括 SparkHadoopKafkaZookeeper 以及 Storm 等等。为了选择最优数据处理工具,需要对分布式 CAP 定理有一个基本认识。

CAP 定理指出,对于一个 分布式系统 ,无法同时满足 一致性Consistency )、 可用性Availability )以及 分区容错性Partition tolerance )。

分布式 CAP 定理在大数据领域非常重要,特别是需要根据使用场景对三点进行权衡时。这篇博客,我将重点阐述 CAP 这三个概念以及抉择考量。由于 数据库管理系统DBMS )发展迅猛,我避免将讨论局限在某个特定系统。

分区容错性

这个条件要求,不管多少消息被节点间网络延迟,系统必须持续运作。一个分区容错的系统,可以容忍任意数量的网络故障,只要不是整个网络都挂掉。数据记录需要充分复制,覆盖各种节点、网络组合,保证系统在网络短暂中断时能够正常服务。设计现代分布式系统时,分区容错性不是一个选择,而是一个必选项。因此,我们需要在一致性和可用性间做选择。

一致性

这个条件要求,同一时间所有节点都看到相同的数据。简而言之,一个读操作必须返回最近写操作写入的值,所有节点都返回相同的数据。如果系统在一致状态下开始事务,事务保证其结束后系统状态也是一致的,系统便满足一致性。在这个模型中,系统可能在事务中进入不一致状态,但是不管事务在哪个执行阶段出错,均可回滚。

如上图,在不同的时间写入两个不同的数据记录( Bulbasaur Pikachu )。 一致性要求任意节点可以读到 Pikachu ,也就是最后写入的值。然而,其他节点更新数据需要时间,网络中将经常有节点不可用。

可用性

这个条件要求,每个请求都得到响应,不管成功还是失败。想达到可用性要求,分布式系统必须在服务时间内 100% 可用。每个客户端请求都能得到响应,不管集群内节点状态如何。评价指标很直观:你是否可以提交读、写操作命令。

这意味着,与上一例子不同,我们无法得知 Pikachu 还是 Bulbasaur 先写,结果可以是二者之一。 因此,在高频率流式数据分析场景,可用性不太可行。

结论

分布式系统 让我们可以达到过去无法想象的 计算能力可用性水平 。现在我们有很多 高性能低延迟 、接近 百分百可用 的系统,跑在全球范围内不同的数据中心。最重要的是,现在的系统可以跑在商用硬件上,容易获得、可配置,而且价格也不高。

然而,代价也是有的。分布式系统比单机系统更加复杂。因此,想更好掌握 水平扩容 技巧,你需要理解分布式系统带来的 复杂性 ,根据开发任务在 CAP 中取舍,并为其选择正确的工具。

小菜学网络】系列文章首发于公众号【小菜学编程】,敬请关注:

【小菜学网络】系列文章首发于公众号【小菜学编程】,敬请关注: