极客时间已完结课程限时免费阅读

02 | CAP理论：分布式系统的PH试纸，用它来测酸碱度

02 | CAP理论：分布式系统的PH试纸，用它来测酸碱度-极客时间

02 | CAP理论：分布式系统的PH试纸，用它来测酸碱度

2020-02-10 韩健 来自北京
《分布式协议与算法实战》
课程介绍

讲述：于航

时长15:26大小14.13M

你好，我是韩健。
很多同学可能都有这样的感觉，每次要开发分布式系统的时候，就会遇到一个非常棘手的问题，那就是如何根据业务特点，为系统设计合适的分区容错一致性模型，以实现集群能力。这个问题棘手在当发生分区错误时，应该如何保障系统稳定运行，不影响业务。
这和我之前经历的一件事比较像，当时，我负责自研 InfluxDB 系统的项目，接手这个项目后，我遇到的第一个问题就是，如何为单机开源版的 InfluxDB 设计分区容错一致性模型。因为 InfluxDB 有 META 和 DATA 两个节点，它们的功能和数据特点不同，所以我还需要考虑这两个逻辑单元的特点，然后分别设计分区容错一致性模型。
那个时候，我想到了 CAP 理论，并且在 CAP 理论的帮助下，成功地解决了问题。讲到这儿，你可能会问了：为什么 CAP 理论可以解决这个问题呢？
因为在我看来，CAP 理论是一个很好的思考框架，它对分布式系统的特性做了高度抽象，比如抽象成了一致性、可用性和分区容错性，并对特性间的冲突（也就是 CAP 不可能三角）做了总结。一旦掌握它，你就像拥有了引路人，自然而然就能根据业务场景的特点进行权衡，设计出适合的分区容错一致性模型。
那么问题来了：我说的一致性、可用性和分区容错性是什么呢？它们之间有什么关系？你又该如何使用 CAP 理论来思考和设计分区容错一致性模型呢？这些问题就是我们本节课所要讲的重点了。我建议你集中注意力，认真学习内容，并学以致用，把 CAP 理论应用到日常工作中。

CAP 三指标

我刚刚提到，CAP 理论对分布式系统的特性做了高度抽象，形成了三个指标：
一致性（Consistency）
可用性（Availability）
分区容错性（Partition Tolerance）
一致性说的是客户端的每次读操作，不管访问哪个节点，要么读到的都是同一份最新写入的数据，要么读取失败。
你可以把一致性看作是分布式系统，对访问自己的客户端的一种承诺：不管你访问哪个节点，要么我给你返回的都是绝对一致的最新写入的数据，要么你读取失败。你可以看到，一致性强调的是数据正确。
为了帮你理解一致性这个指标，我给你举一个具体的例子。比如，2 个节点的 KV 存储，原始的 KV 记录为“X = 1”。
紧接着，客户端向节点 1 发送写请求“SET X = 2”。
如果节点 1 收到写请求后，只将节点 1 的 X 值更新为 2，然后返回成功给客户端。
那么，此时如果客户端访问节点 2 执行读操作，就无法读到最新写入的 X 值，这就不满足一致性了。
如果节点 1 收到写请求后，通过节点间的通讯，同时将节点 1 和节点 2 的 X 值都更新为 2，然后返回成功给客户端。
那么在完成写请求后，不管客户端访问哪个节点，读取到的都是同一份最新写入的数据，这就叫一致性。
一致性这个指标，描述的是分布式系统非常重要的一个特性，强调的是数据正确。也就是说，对客户端而言，每次读都能读取到最新写入的数据。
不过集群毕竟不是单机，当发生分区故障的时候，有时不能仅仅因为节点间出现了通讯问题，无法响应最新写入的数据，之后在客户端查询数据时，就一直返回给客户端出错信息。这句话怎么理解呢？我来举个例子。
业务集群中的一些关键系统，比如名字路由系统（基于 Raft 算法的强一致性系统），如果仅仅因为发生了分区故障，无法响应最新数据（比如不满足“大多数”，没有了领导者），为了不破坏一致性，那么客户端查询相关路由信息时，系统就一直返回给客户端出错信息，此时相关的业务都将因为获取不到指定路由信息而不可用、瘫痪，这可以说是灾难性的故障了。
这个时候，我们就需要牺牲数据正确，每个节点使用本地数据来响应客户端请求，来保证服务可用，这就是我要说的另外一个指标，可用性。
可用性说的是任何来自客户端的请求，不管访问哪个非故障节点，都能得到响应数据，但不保证是同一份最新数据。你也可以把可用性看作是分布式系统对访问本系统的客户端的另外一种承诺：我尽力给你返回数据，不会不响应你，但是我不保证每个节点给你的数据都是最新的。这个指标强调的是服务可用，但不保证数据正确。
我还是用一个例子，帮助你理解一下。比如，用户可以选择向节点 1 或节点 2 发起读操作，如果不管节点间的数据是否一致，只要节点服务器收到请求，就响应 X 的值，那么，2 个节点的服务是满足可用性的。
最后的分区容错性说的是，当节点间出现任意数量的消息丢失或高延迟的时候，系统仍然在继续工作。也就是说，分布式系统在告诉访问本系统的客户端：不管我的内部出现什么样的数据同步问题，我会一直运行。这个指标，强调的是集群对分区故障的容错能力。
来看下面的图，当节点 1 和节点 2 通信出问题的时候，如果系统仍能继续工作，那么，2 个节点是满足分区容错性的。
因为分布式系统与单机系统不同，它涉及到多节点间的通讯和交互，节点间的分区故障是必然发生的，所以我要提醒你的是，在分布式系统中分区容错性是必须要考虑的。
现在你了解了一致性、可用性和分区容错性，那么你在设计分布式系统时，是选择一致性？还是可用性？还是分区容错性？还是都可以选择呢？这三个特性有什么冲突么？这些问题就与我接下来要讲的“CAP 不可能三角”有关了。

CAP 不可能三角

CAP 不可能三角说的是对于一个分布式系统而言，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）3 个指标不可兼得，只能在 3 个指标中选择 2 个。
CAP 不能三角最初是埃里克·布鲁尔（Eric Brewer）基于自己的工程实践，提出的一个猜想，后被赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）证明，证明过程可以参考论文《Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services》，你记住结论就好了。不过，为了帮你阅读论文，我补充一点：
基于证明严谨性的考虑，赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）对指标的含义做了预设和限制，比如，将一致性限制为原子一致性。
说了这么多，那么 CAP 理论是怎么解决我在开篇提到的问题呢？或者说，你要如何使用 CAP 理论来思考和设计分区容错一致性模型呢？

如何使用 CAP 理论

我们都知道，只要有网络交互就一定会有延迟和数据丢失，而这种状况我们必须接受，还必须保证系统不能挂掉。所以就像我上面提到的，节点间的分区故障是必然发生的。也就是说，分区容错性（P）是前提，是必须要保证的。
现在就只剩下一致性（C）和可用性（A）可以选择了：要么选择一致性，保证数据正确；要么选择可用性，保证服务可用。那么 CP 和 AP 的含义是什么呢？
当选择了一致性（C）的时候，一定会读到最新的数据，不会读到旧数据，但如果因为消息丢失、延迟过高发生了网络分区，那么这个时候，当集群节点接收到来自客户端的读请求时，为了不破坏一致性，可能会因为无法响应最新数据，而返回出错信息。
当选择了可用性（A）的时候，系统将始终处理客户端的查询，返回特定信息，如果发生了网络分区，一些节点将无法返回最新的特定信息，它们将返回自己当前的相对新的信息。
这里我想强调一点，大部分人对 CAP 理论有个误解，认为无论在什么情况下，分布式系统都只能在 C 和 A 中选择 1 个。其实，在不存在网络分区的情况下，也就是分布式系统正常运行时（这也是系统在绝大部分时候所处的状态），就是说在不需要 P 时，C 和 A 能够同时保证。只有当发生分区故障的时候，也就是说需要 P 时，才会在 C 和 A 之间做出选择。而且如果读操作会读到旧数据，影响到了系统运行或业务运行（也就是说会有负面的影响），推荐选择 C，否则选 A。
那么我当时是怎么根据场景特点，进行 CAP 权衡，设计适合的分布式系统呢？为了便于你理解，我先来说说背景。
开源版的 InfluxDB，缺乏集群能力和可用性，而且，InfluxDB 是由 META 节点和 DATA 节点 2 个逻辑单元组成，这 2 个节点的功能和数据特点不同，需要我们分别为它们设计分区容错一致性模型。
InfluxDB程序的逻辑架构示意图
我具体是这么设计的：
作为分布式系统，分区容错性是必须要实现的，不能因为节点间出现了分区故障，而出现整个系统不工作的情况。
考虑到 META 节点保存的是系统运行的关键元信息，比如数据库名、表名、保留策略信息等，所以必须实现一致性。也就是说，每次读，都要能读取到最新数据，这样才能避免因为查询不到指定的元信息，时序数据记录写入失败或者系统没办法正常运行。比如，创建了数据库 telegraf 之后，如果系统不能立刻读取到这条新的元信息，那么相关的时序数据记录，就会因为找不到指定数据库信息而写入失败，所以，我选择 CAP 理论中的 C 和 P，采用 CP 架构。
DATA 节点保存的是具体的时序数据记录，比如一条记录 CPU 负载的时序数据，“cpu_usage,host=server01,location=cn-sz user=23.0,system=57.0”。虽然这些数据不是系统运行相关的元信息，但服务会被访问频繁，水平扩展、性能、可用性等是关键，所以，我选择了 CAP 理论中的 A 和 P，采用 AP 架构。
你看，我用 CAP 理论进行思考，并分别设计了 InfluxDB 的 META 节点和 DATA 节点的分区容错一致性模型，而你也可以采用类似的思考方法，设计出符合自己业务场景的分区容错一致性模型。
那么假设我当时没有受到 CAP 理论的影响，或者对 CAP 理论理解不深入，DATA 节点不采用 AP 架构，而是直接使用了现在比较流行的共识算法，比如使用 Raft 算法，会有什么痛点呢？
受限于 Raft 的强领导者模型。所有写请求都在领导者节点上处理，整个集群的写性能等于单机性能。这样会造成集群接入性能低下，无法支撑海量或大数据量的时序数据。
受限于强领导者模型，以及 Raft 的节点和副本一一对应的限制，无法实现水平扩展，分布式集群扩展了读性能，但写性能并没有提升。这样会出现写性能低下，和因为架构上的限制，无法提升写性能的问题。
关于 Raft 算法的一些细节（比如强领导模型），我会在 07 讲详细带你了解，这里你知道有这么回事儿就可以了。
那么在这里，我也想考考你：如果 META 节点采用 AP 架构，会有什么痛点呢？你可以思考一下。

内容小结

本节课我主要带你了解了 CAP 理论，以及 CAP 理论的应用，我希望你明确的重点如下：
CA 模型，在分布式系统中不存在。因为舍弃 P，意味着舍弃分布式系统，就比如单机版关系型数据库 MySQL，如果 MySQL 要考虑主备或集群部署时，它必须考虑 P。
CP 模型，采用 CP 模型的分布式系统，舍弃了可用性，一定会读到最新数据，不会读到旧数据。一旦因为消息丢失、延迟过高发生了网络分区，就影响用户的体验和业务的可用性（比如基于 Raft 的强一致性系统，此时可能无法执行读操作和写操作）。典型的应用是 Etcd，Consul 和 Hbase。
AP 模型，采用 AP 模型的分布式系统，舍弃了一致性，实现了服务的高可用。用户访问系统的时候，都能得到响应数据，不会出现响应错误，但会读到旧数据。典型应用就比如 Cassandra 和 DynamoDB。
在多年的开发实践中，我一直喜欢埃里克·布鲁尔的猜想，不是因为它是 CAP 理论的本源，意义重大，而是因为它源自高可用、高扩展大型互联网系统的实践，强调在数据一致性（ACID）和服务可用性（BASE）之间权衡妥协。在我看来，CAP 理论像 PH 试纸一样，可以用来度量分布式系统的酸碱值，帮助我们思考如何设计合适的酸碱度，在一致性和可用性之间进行妥协折中，设计出满足场景特点的分布式系统。关于酸（Acid）和碱（Base），我会在 03 和 04 讲带你了解。
最后我想说的是，在当前分布式系统开发中，延迟是非常重要的一个指标，比如，在 QQ 后台的名字路由系统中，我们通过延迟评估服务可用性，进行负载均衡和容灾；再比如，在 Hashicorp/Raft 实现中，通过延迟评估领导者节点的服务可用性，以及决定是否发起领导者选举。所以，我希望你在分布式系统的开发中，也能意识到延迟的重要性，能通过延迟来衡量服务的可用性。

课堂思考

既然我提了 CAP 理论是一个很好的思考框架，能帮助我们思考，如何进行权衡，设计适合业务场景特性的分布式系统，那么你不妨思考一下，CP 模型的 KV 存储和 AP 模型的 KV 存储，分别适合怎样的业务场景呢？欢迎在留言区分享你的看法，与我一同讨论。
最后，感谢你的阅读，如果这节课让你有所收获，也欢迎你将它分享给更多的朋友。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 33

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
加餐 | 拜占庭将军问题：如何基于签名消息实现作战计划的一致性？
下一篇
03 | ACID理论：CAP的酸，追求一致性
 写留言

精选留言(69)

  • Sinclairs
    2020-02-10
    CP模型的KV存储，适合用于提供基础服务，保存少量数据，作用类似zookeeper。 AP模型的KV存储，适合查询量大的场景，不要求数据的强一致性，目前广泛应用于分布式缓存系统。 一点思考，不知道对不对？

    作者回复: 加一颗星:)，能否容忍的可能的短暂的一致性延迟，是关键。

    共 3 条评论
    59
  • 大漠胡萝卜
    2020-02-11
    网络分区，怎么理解？

    作者回复: 网络分区是指因为网络故障导致网络不连通，不同节点分布在不同的子网络中，各个子网络内网络正常。其实，你可以这么理解，节点之间的网络通讯出现了消息丢失、高延迟的问题。

    共 2 条评论
    33
  • 陈
    2020-02-14
    cp模型适合要求acid场景，比如银行转账。ap模型适合只要求base的场景，比如网页cdn场景，不知道理解得对不对。

    作者回复: 加一颗星:)

    24
  • enjoylearning
    2020-02-11
    还是不太明白分区容错性P和可用性A的区别，不都是随时可以提供服务吗？

    作者回复: 可以这么理解，分布式系统是必须要考虑分区容错性的，也就是说，出现分区错误时，比如节点间通讯丢消息了，系统要能运行，那么，这时候如何运行呢？是选择一致性呢，还是选择可用性呢。

    共 27 条评论
    20
  • zjm_tmac
    2020-02-10
    这里的节点1同步给节点2指的是日志复制还是等待节点2的事务提交完成？ 如果是日志复制的话，会不会两边提交事务的时间不一致，造成读取不一致。 如果是等待事务提交的话，是不是变成了完全阻塞的，性能很低还有各种各样问题。

    作者回复: 加一颗星:)。这里是简化表示，比如你可以理解成二阶段提交的事务。关于第一个“如果”，多节点的副本是无法做到完全同时完成提交的，但能保证写完成后，读取都是一致的；如果需要实现读取的严格一致性，比如，可以通过实现“Master-Slave”模型，读写只访问Master节点，实现读取的严格一致性；第二个“如果”，就是常见事务型系统的缺点。

    共 2 条评论
    19
  • iron_man
    2020-02-23
    知乎上看到的，与各位分享 一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。 作者：邬江 链接：https://www.zhihu.com/question/54105974/answer/139037688 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
    展开

    作者回复: 前半部分的容忍性，其实指的的是可用性，做法是分区部署、增加数据缓存，提升可用性。分区容错性是一种行为，指的是分区错误发生时，系统依然能提高服务，这时可以提供的服务，有两种，一致性和可用性，需要注意的是，有些服务是要求一致性的，也就是说，增加集群副本数，是不能解决问题的。可用性，就比较好理解了，但在实际中，仅仅增加副本数或缓存是不够的，还需要全方位的监控能力、高灵敏的故障检测能力、全网的调度能力，等等。

    共 4 条评论
    17
  • 霹雳大仙pp
    2020-03-09
    以阿里nacos来说，配置中心是cp，保证各节点配置强一致；注册中心是ap，保证了可用性，牺牲了强一致性。

    作者回复: 加一颗星:)

    15
  • NICK
    2020-02-23
    可不可以理解成在分布式场景下: 1. 如果业务需要强一致性，则只能牺牲可用性而选择CP模型。 2. 如果业务需要最终一致性即可，则优先满足可用性，选择AP模型？

    作者回复: 加一颗星:)

    11
  • longyi
    2020-02-19
    受限于 Raft 的强领导者模型。所有请求都在领导者节点上处理，整个集群的性能等于单机性能。这样会造成集群接入性能低下，无法支撑海量或大数据量的时序数据。 //老师，这里应该是所有的写请求都在领导者节点上处理吧？ //另外，如果采用multi-raft，每个raft分片都有自己的leader，这样请求将不限于节点，而是在分片的leader上，这样性能也没那么差，老师觉得呢？

    作者回复: 加一颗星:)，是写请求，相比Raft，Multi-Raft是有改进的，但和最终一致性的方案相比，还是有差距。其实，Raft不适合时序数据场景，比如，如果即使采用multi-raft，因为时序数据，有时需要拉取一批数据，这时需要在外围，再实现分布式迭代器，工作量，还是蛮大的；另外，在Raft中，uncommitted的log，可能被丢弃了，也可能在后面被提交了，也就是说，当Raft返回给客户端超时错误时，数据是否会被提交，是个不确定状态，如果这时，客户端不重试，可能会丢数据，如果客户端重试，对于没有带时间戳的时序数据，会导致数据重复，当然，我们可以通过重新约定InfluxDB行为、实现冥等操作等，来解决这个问题，但这样做，不仅增加工作量和系统复杂度，还影响用户的体验；还有最后一点，也就是最最重要的，高性能的背后，是成本，是钱，这个经济效益，会在海量数据场景，被放大，性能是最核心的一个考虑因素。

    共 2 条评论
    8
  • 约书亚
    2020-02-11
    有个问题想不通，求助一下》 在如何使用CAP理论一节，但就文中定义来说: 选择C时拒绝的是"写入"。选择A时，讨论的是"返回"相对新的信息。 请问，根据这样的定义，某些基于raft的系统中(比如consul)，在分区后，在少数分区一方的拒绝写入，就满足了C，而任何一个节点都支持读取陈旧的数据，又满足了A。CAP齐全，这不是矛盾了么？ 我查阅了些资料包括维基百科，对C和A的定义也都如此。 我发现<<designing data-intensive applications>>这本书里有简单的用写入或读取这样的字样，而是一直用"线性一致性"（p336）。 CP的KV存储一般都被借助用于提供给次级应用做严格的一致性的保障。 AP的KV存储一般都被用于海量数据高并发需求下的数据操作，或者是多可用区高延迟的场景下的最终一致性保障。
    展开

    作者回复: 这里，是从大家在日常实践中，最直观感受的角度，进行表述的，一致性，最直观的，是影响到写，可用性，最直观的，是还能读到相对新的数据。你可以这么理解，当发生分区错误是，选择了C，新数据，都无法写入了，那就可能也不能读取了；选择了A，新数据，在部分节点上，能写入，也能被业务读取。 另外，Raft是一个共识算法，“大多数的约定”赋予了它容错能力，也就是少部分节点故障时，集群是正常运营和写入的。但需要你注意的是，Raft实现的是大多数节点间的数据的共识，不是数据副本的强一致性，分布式事务是实现强一致性的，你可以想象下，分区错误了，分布式事务是无法提交的，也就是新数据，是无法写入的。

    共 10 条评论
    7
  • 小跑
    2020-02-14
    怎么觉得etcd-raft不是严格意义上的一致性，是线性的，只要满足大多数的情况下，哪怕个别节点挂掉，也能对外提供读写服务，所以从这个角度看，它其实一种ap模型吧。

    作者回复: Raft是具有容错能力的共识算法，可以用来实现一致性，比如，类似Google Chubby，读写操作都在领导者节点上执行。 可以这么理解，分布式事务实现的是一致性，不能容忍任何节点出问题；只要集群中有一个节点，都能继续提供服务，可以把这个理解为可用性。而Raft等共识算法，能容忍少数节点的故障，但通过读写操作都在领导者节点上执行，也能为业务提供一致性的数据服务，可以将共识算法理解为对分布式事务型算法的改进，既有容错能力，又能提供一致性。

    6
  • 向前走
    2020-04-25
    可用性和分区容错性理解上感觉有点类似，都是保证能提供服务，这两个主要的区别是什么呢，老师

    作者回复: 加一颗星:)，为了更好理解，我在内容上做了微调，避免了重复出现”提供服务“。分区容错性，说的是，出现分区错误时，系统要能继续运行，这时有两个选择，一致性和可用性。举个例子，2服务器节点，把网线剪断了，这时系统接收到来自客户端的读请求时，有2个选择：1，选择一致性，因不能响应最新数据，而返回出错给客户端；2，选择可用性，响应本地数据给客户端，也就是旧数据。此时，只能在C和A中，二选一。

    共 2 条评论
    5
  • Skysper
    2020-02-19
    文中说节点1和节点2通信异常的时候，仍然能够提供服务，是满足分区容错性的，那么这个仍然能够提供服务怎么理解？是不是同时体现了可用性（一个分区容错性体现了两个特性）？可用性与分区容错性是不是存在一定的边界？同样如果是满足CP的情况下，是不能写入，还可以读吗？或者都不可以，如果都不可以，是不是又不满足P了呢？

    作者回复: 分布式系统是必须要考虑分区容错性的，也就是说，出现分区错误时，比如节点间通讯丢消息了，系统要能正常运行，那么，这时候如何运行呢？是选择一致性呢，还是选择可用性呢，满足P的时候，C和A是有矛盾的。 选择了CP，可以读，可以这么理解，网络分区时，读操作，不影响一致性。

    共 3 条评论
    5
  • zmysang
    2020-02-15
    如果meta节点采用ap架构，在网络分隔的情况下，分隔的节点之间独立，各自接收到请求后自行处理，不会进行数据同步，导致不同meta节点上的元数据信息不一致。那么在数据请求的过程，可能会出现对不同节点发送请求有的可以成功有的不能成功的情况，这其实也会造成一种不可用的情况。 针对CP 模型的 KV 存储和 AP 模型的 KV 存储，分别适合怎样的业务场景呢？ 针对cp模型的kv存储，适用于对数据的一致性以及可靠性要求比较高的情况； 针对ap模型的kv存储，适用于对延迟要求比较高，对数据一致性要求没有那么高的情况。
    展开

    作者回复: 加一颗星:)

    5
  • 宁悦
    2020-05-23
    12306抢票的时候的余票查询是一个AP模型，不管在哪里都能查询到票数，但是票数不一定和实际票数相匹配。 购买车票的时候就是一个CP模型，不管从哪里访问，能不能买到票都是一致的。 就导致明明查询余票的时候有票，但是真正买的时候没票的情况。

    作者回复: 加一颗星:)

    3
  • QQ怪
    2020-04-16
    看完老师的例子感觉对cap又有新的认识和理解

    作者回复: 加一颗星:)，多交流:)

    3
  • 密码123456
    2020-03-03
    分区容错性和可用性。有点分不清，我感觉说的是一回事啊！都是对外提供可用的服务。

    作者回复: 加一颗星:)，这么理解，当发生分区错误时，系统在运行，那么如何运行呢？要在一致性和可用性中选择一个，这两个是不能同时满足的，如果选择了一致性，能一直读到新数据，但在分区错误发生时，可能因为系统无法响应最新数据，而读取数据失败；如果选择了可用性，每次读操作都会得到响应，但会读到旧数据。

    共 3 条评论
    3
  • Jaime
    2020-08-10
    假设meta节点选择了ap，有一种情况当data节点扩容的时候，因为要做机器间的数据平衡和迁移，那么元数据信息就会发生改变，如果meta节点是ap的时候，客户端读取数据就可能拿到不是最新的元信息，就会发生往data节点写入失败或者查找失败的问题，不知道我说的这种情况对不对?

    作者回复: 加一颗星:)，是的。

    2
  • Geek_9ad555
    2020-07-21
    打卡总结下： 1.要想分布式系统稳定运行，首先必须保证内部问题得到解决，不能出现多个山头，也就是分区容忍性。 2. 一致性 分为强一致性，弱一致性，和最终一致性。 a. 强一致性 对错误零容忍，一点儿错就导致全部不可用 b.弱一致性允许数据不准确 c.最终一致性允许在运行过程中不一致，但是最终必须一致 3. 可用性
    展开

    作者回复: 加一颗星:)

    1
  • funnyx
    2020-06-12
    老师您好，如果在保证分区容错的前提下，两个节点数据同步不及时，会产生数据不一致问题，那这种应该如何处理？是从客户端角度考虑还是从服务端架构重新考虑？

    作者回复: 加一颗星:)，节点的数据不一致，不是问题，因为我们可以通过实现相应的读操作，来实现一致性，比如，限制读操作只能在Raft的领导者节点上执行，来实现强一致性。再或者，主备架构，在故障切换后，实现双读，来保证一定能读取到最新的数据。

    共 2 条评论
    1