作风建设年活动网站,运维网站制作,国外分销平台有哪些,微信模板消息谈到 NoSQL#xff0c;一定会提及一致性#xff08;Consistency#xff09;#xff0c;按照 CAP 定理#xff0c;有些 NoSQL 数据库放弃了一致性#xff0c;但是 NoSQL 放弃是必然的选择吗#xff1f;
从 1970’s#xff0c;关系型数据库#xff08;RDB#xff0c;R…谈到 NoSQL一定会提及一致性Consistency按照 CAP 定理有些 NoSQL 数据库放弃了一致性但是 NoSQL 放弃是必然的选择吗
从 1970’s关系型数据库RDBRelational Database被发明以来关系型数据库就是构建应用的通常的选择。关系型数据库对用户提供 ACID 保证非常方便开发者使用。从 1990’s 开始NoSQL 系统开始出现。NoSQL 系统是一类对立于关系数据库的数据库系统他们从架构上放弃了传统的关系型数据库的的关系模型和 SQL 的接口。
与 NoSQL 系统相伴而来的 2 个词是 BASE 和 CAP这 2 个词对分布式系统有着非常深远的影响。我相信就是在这 2 个词的影响下很多 NoSQL 系统从架构的初始就放弃了一致性consistency选择了一种最终一致性Eventual consistency和可用性 (Availability)。虽然我非常认同 CAP 和 BASE 这 2 个词但是我不认为在 CAP 和 BASE 的作用下NoSQL 系统选择放弃一致性是一个必然的事情。
首先来回顾一下 CAP 和 BASE 这 2 个概念的历史。这 2 个概念都是由 Eric Brewer 提出的Brewer 目前是 Google 公司的基础设施部门Infrastructure的副总裁VPVice President。在 1997 年在 SOSP(Symposium on Operating Systems Principles) 上名为的演讲 [1] 总结了 Brewer 等人的近期工作演讲中说他们正在工作的集群服务并没有采用当时公认的具有 ACID 特性的关系型数据库作为架构而是在架构上放弃了关系型数据库的 ACID 特性。并且为他们的这个架构选择构造了一个新的词 BASEBASE 这个词的选择有刻意为之成分ACID 在英语里有酸性的意思而 BASE 有碱性的意思很明显 BASE 是与?ACID 对立的。
ACID 和 BASE 分别是如下单词的首字母缩写 ACIDAtomicity, Consistency, Isolation, Durability BASE: Basically Available, Soft State, Eventual Consistency
BASE 主张放弃掉 ACID主要是放弃 ACID 中的 Consistency并且让系统达到基本可用Basically Available柔性状态Soft State最终一致Eventual Consistency。系统构建者可以不仅仅选择 ACIDBASE 也称为一种选择也就是在 ACID 和 BASE 中选择其一。本质上来讲就是在 ACID 代表的一致性 (Consistency) 和 BASE 代表的可用性Availability二者之间做出选择。虽然在 BASE 提出时还没有明确说明在一致性和可用性间做出架构选择但是已经为后面 CAP 的提出做好了伏笔。
到 2000 年Brewer 在 PODCPrinciples of Distributed Computing做了名为 [2] 的演讲演讲的主旨是阐明如何构建健壮的分布式系统。在这次演讲中Brewer 近一步分析比较了 ACID 和 BASE并且抽象了 ACID 和 BASE 的核心特性也就是 ACID 的一致性ConsistencyBASE 的可用性Availability并且扩展了第 3 个维度也就是网络分区Network Partition从而提出了CAP 猜想这个猜想说
在分布式系统中最多能同时满足以下 3 个属性中的 2 个 C Consistency, A Availability, P Tolerance to network Partitions
根据这个猜想会存在 3 类系统
放弃 P系统具有 CA 特性这类系统诸如单机数据库 放弃 A系统具有 CP 特性这类系统诸如分布式数据库、分布式锁 放弃 C系统具有 AP 特性这类系统诸如 web caching、DNS 可用性是非常重要的一个特性特别是在互联网行业中服务宕机对商业的影响是非常大的所以依据 CAP 定理放弃一致性也就是自然的选择了。特别是在 Amazon 的 CTO Werner Vogels 详细介绍了 Eventually Consistent[5] 和 Amazon 的 Dynamo 系统的论文 [12] 发表后大量追求可用性放弃一致性的 NoSQL 系统出现。
到了 2002 年GilBert 和 Lynch[3]重新定义了 CAP 这 3 个属性重新定义的属性比 Brewer 猜想中的属性的范围小了很多并且证明了 CAP 这 3 个属性不能同时达到从而将 CAP 猜想变成了CAP 定理。
CAP 定理中的 3 个属性定义如下 [3,6] Consistency: 是指原子一致性Atomic consistency或者线性一致性linearizable consistency这是一种非常高的一致性级别很少有系统能够达到。 Availability: 是指完全的可用性也就是每个到达每个没有宕机的节点上的读写请求都能在一个合理的时间返回一个响应。这里的关键点是每个请求到达每个非宕机的节点。这也是一种非常高的可用性水平也很少有系统能够达到。 Partition Tolerant: 是指系统能够在出现网络分区的情况下继续正确响应即保持系统该有的特性或者说保持一致性或者可用性。
Glibert 和 Lynch 重新定义的 CAP 定理非常严谨但是只证明了 3 个属性不能同时具有。然而 Brewer 猜想中的 3 个属性的定义、3 选 2 的描述3 分的分类法AP,CP,CA3 种分类却不是非常严谨这也是 CAP 出现之后很多人怀疑和挑战 CAP 的原因。Brewer 在 2012 年重新写了一篇文章 [4]也承认最初的 CAP 表述非常令人误解。事实上CAP 定理的适用范围是非常小的。 虽然 CAP 从出生开始就有很多问题但是它仍然推动了 NoSQL 运动很多系统架构者依据 CAP 定理主动放弃了一致性但实际上很多时候这些系统都是不满足 CAP 定理的适用范围的。
CAP 的故事到此并未完结2017 年Brewer 已经是 Google 公司的基础设施Infrastructure部门的副总裁VPVice President了并且这时 Google 公司的第一代 Spanner 系统已经诞生 [9]。Brewer 写了一篇文章讲述了 Google 公司的 Spanner 系统 [7]并且近一步阐述了按照 CAP 定理 Spanner 是一个什么样特性的系统。在文中Brewer 指出 Spanner 系统说是 实际上的 CAeffectively CA系统。从架构上来讲Spanner 是一个 CP 系统也就是说当出现网络分区时Spanner 选择的是保证数据的一致性放弃可用性的。但实际上Spanner 是具有非常高可用性效果的一个系统从架构上 Spanner 没有达到 CAP 定理要求的那种完全可用性但是也达到非常高的可用性由于采用多副本的设计个别副本出现网络分区并不影响用户能感知到的可用性。按 CAP 定理的定义当这些个别副本出现网络分区时这些节点是不可用的也就是系统没有达到完全可用性。但是此时的用户请求是可以被其他副本服务的此时服务是可用的也就是说用户仍然感知到 Spanner 是可用的。所以说用户感知的可用性和 CAP 定理中的可用性不是一个概念。我们追求的应该是用户感知的可用性。
用户可感知的可用性通常用 SLA 来表示也就是我们通常说的几个 9 的可用性。Brewer 在文章中也给出了 Google 关于 Spanner 系统的 SLA 的数据从数据我们可以看到由于网络分区导致的服务可用的比例是比较小的有很大一部分导致服务不可用的原因是诸如软件 bug、配置错误、运维误操作等导致的。也就是说即便在架构上采用了达到 CAP 定理要求的可用性实际用户可感受到的服务可用性也就 SLA 也不会提高多少。这也是我从业这么多年的一个体会系统的不稳定更多来自系统开发者的日常失误加强代码质量加强开发流程规范加强生产运维规范更能大大提高系统的可用性。所以在架构层面因为可用性放弃一致性往往是得不偿失的。
云计算的大潮下不放弃一致性也是非常明智的。一个托管在云上的数据存储服务如果你放弃了一致性选择可用性用户是感受不明显因为使用者不会对架构设计采用达到的 CAP 定理的可用性而买单用户只会为你的服务达到 SLA 买单。然而数据存储服务是否具有一致性用户是能够非常明显的感受到的。Amazon 公司的内部的 Dynamo[12] 在架构上是可以达到 CAP 定理中的可用性要求的但是 Amazon 在 AWS 云上售卖的 DynamoDB 并不是采用的这一架构也许就是出于这个原因 [10]。
那么我们选择一致性得到的好处是什么那很多时候说到一致性时都会拿金融和钱相关的例子来说明一致性的必要性但是我相信金融行业并不强依赖一致性 [10]。我认为一致性给我带来的是开发的方便性。Brewer 虽然提出了 BASE 概念但是他并没有详细阐述这个概念。2008 年 EBay 公司的 Dan Pritchett写了一遍文章 [8]通过举例详细阐述了在放弃了 ACID 以后如何采用 BASE 架构实现相同的需求向我们推荐了 BASE 这种架构模式。通过这篇文章我们我可以看到如果放弃了 ACID 而选择 BASE 的话本来一个非常简单的功能需要加入消息队列等手段才能让系统达到最终一致性应用的整体架构复杂了很多。
类似于 Pritchett 文章中说明的一样使用不具有一致性的 NoSQL 系统你需要仔细甄别你的使用场景判断你的使用场景是否可以让你放弃一致性。即便你要使用 BASE 架构也不是简单地采用一个具有最终一致性的 NoSQL 系统替换掉 ACID 数据库就好了你需要设计好各种手段处理掉具有最终一致性的 NoSQL 系统带来的异常让你的整个应用达到柔性状态和最终一致。BASE 中所说的最终一致和很多 NoSQL 系统所具有的最终一致有些细微的差别。这个差别简单来说是BASE 中所说的最终一致是保证系统状态是正确的而很多 NoSQL 系统最终一致只保证最终一致但是不保证这个状态是你想要的正确的状态 [11]。
最后个人的一个观点是如果一个 NoSQL 系统做为缓存使用为了追求低延时可以放弃一致性大数据和离线计算的场景类似于这种场景很多 NoSQL 系统是非常适用的但是如果 NoSQL 系统作为数据库来用那么这个 NoSQL 系统最好不要因为可用性放弃一致性同时通过多副本技术和良好运维达到实际的高可用性即达到实际上的 CAeffectively CA这样可以大大降低使用者的使用负担。
由于篇幅所限本文中关于一致性、CAP、BASE、ACID 的很多技术细节的阐述未能详尽拟另行成文讨论。成文仓促有错漏之处欢迎各位大神指正。
原文链接 本文为云栖社区原创内容未经允许不得转载。
