数据库的CAP理论:一致性、可用性以及分区容忍性
乔纳珊.约翰逊
2020.12.9
译者:东南门吹雪
2023.4.14
CAP理论是来自理论计算机科学关于分布式数据存储的一个信念,它断言:假如分布式数据库发生网络失败,则只能提供一致性、可用性二者之其中一项,而不是全部两者。
让我们一起来看下:
什么是CAP理论
CAP理论由3个部分组成(也是名字的由来):
>一致性,全部读操作收到最新的写入或一个错误(error)。
>可用性,全部读都包含数据,但可能不是最新的。
>分区容忍性,即使网络失败(也就是失联的分区、慢网络连接,或节点间不可用的网络连接),系统也继续运转。
在正常的系统运转中,你的数据存储提供全部三项职能。但是CAP理论坚持认为:当分布式数据库经历网络失败时,你能提供要么一致性,要么可用性。
这是一个权衡。其它的全部时间里,三项是全部可以提供的。但是万一网络失败,则必须做出一个取舍。
在这个理论中,分区容忍性是必须的。其假设系统运行在分布式数据存储之上,所以系统天然伴随着网络分区而运转。网络分区会发生,所以为了提供任何类型的可靠服务,分区容忍性是必要的——CAP中的P。
然后剩下在C与A两者之间的决定。当网络失败发生时,人们可以选择保证一致性或者可用性:
>高一致性带来更低的可用性的代价
>高可用性带来更低的一致性的代价
在CAP中的一致性(Consistency)跟ACID中的一致性(Consistency)概念不同。CAP中的一致性表示有最时新的信息。(ACID指另一个不同的数据库事件。在ACID,一致性表示任何新的数据库事务不会破坏数据库的正确性)
用户查询:一致的或可用的
现在思考一下用户查询的问题。我们假定一个用户对一个数据库做一个查询,然后这个网络数据库要返回一个值。
无论从数据库返回哪个值,都依赖于我们是提供一致性还是可用性的选择。这里看下这种选择过程的来龙去脉:
>发生一个查询时,我们使用服务器上的当前值向用户响应,以提供一个高可用的服务。如果我们这样做,就不能保证返回的值是最新提交到数据库的。可能最新的写入还卡在某处的传输过程中。
>如果我们要保证高一致性,则我们不得不等待这个新的写入或者针对这次查询返回一个错误。因此,我们牺牲了可用性来确保查询返回的数据是一致的。
选择系统需要的
对于有些人,在一致性与可用性之间的选择真正是一个哲学讨论的课题,实际上很少做过。这些分布式系统的可靠性是相当的好。即便如此,问题确实发生了。AWS就刚刚在2020年感恩节之前经历了一次大停电。
这个理论说在三个特性中你们只能拥有两个选择,而专业人员说情况并不总是如此。Eric Brewer,计算机科学家与CAP理论的初始提出者,澄清了一些关于这个理论的困惑,将它从僵硬的“不是/就是‘’说法扩展到依赖于系统的需要。他说:
现代的CAP目标应该是一致性与可用性的最大的结合,这对于特定应用有意义。这样一种方法包含网络分区期间的操作与后期恢复的计划,从而帮助设计者超越它历史以来被意识到的限制来思考CAP。
挑选哪种数据库类型时,一致性与可用性的选择随之而来,比如SQL对NoSQL。NoSQL数据库可以基于是否支持高可用性或高一致性来进行分类。
NoSQL
NoSQL数据库不需要“预定义的模式规范”(SCHEMA),并且不强制表间的关系。它的全部文档都是JSON文档,是完整的实体,人们可以方便地阅读与理解。他们广泛被认为:
易用
性能可扩展
恢复力强
广泛的可用性
NoSQL数据库例子包括:
>Cloud Firestore
>Firebase Real-time DB
>MongoDB
>MarkLogic
>Couchbase
>CloudDB
>Amazon DynamoDB
数据库中的一致性
当返回信息值需要保证准确,则应该使用强一致性数据库。
金融数据是一个好的例子。当一个用户登录到他们的银行业务机构时,他们不想看到一个无数据返回的错误、或相比实际数值偏高或偏低。银行业务APP应该返回用户账户信息的准确数值。这种情况下,银行应该依赖强一致性数据库。
强一致性数据库例子包括:
>银行账户余额
>文本信息
一致性数据库选项:
>MongoDB
>Redis
>HBase
数据库中的可用性
当服务比信息更加重要时,应该使用强可用性数据库。
一个使用高可用性数据库的例子可以在电子商务业务中看到。在线商店想要使他们的商店和购物车功能7*24小时可用,从而使购物者可以按需随时购物。
强可用性数据库选项:
>Cassandra
>DynamoDB
>Cosmos DB
一些候选数据库,比如Cosmos 和Cassandra,允许用户操作一个旋钮,来确保他们的偏好:一致性或者可用性。