关于分布式:分布式要点数据复制

复制次要指通过互联网在多台机器上保留雷同数据的正本。通过数据复制计划，人们通常心愿达到以下目标:

• 使数据在地理位置上更靠近用户，从而 升高拜访提早。
• 当局部组件呈现故障，零碎仍然能够持续工作，从而 进步可用性。
• 扩大至多台机器以同时提供数据拜访服务，从而 进步读吞吐量。

主节点与从节点

每个保留数据库残缺数据集的节点称之为正本。对于每一笔数据写入，所有正本都须要随之更新；否则，某些正本将呈现不统一。最常见的解决方案是基于主节点的复制（也称为被动 / 被动，或主从复制）。主从复制的工作原理如下：

1. 指定某一个正本为主正本。当客户写数据库时，必须将写申请首先发送给主正本，主正本首先将新数据写入本地存储。
2. 主正本把新数据写入本地存储后，而后将数据更改作为复制的日志或更改流发送给所有从正本。每个从正本取得更改日志之后将其利用到本地，且严格放弃与主正本雷同的写入程序。
3. 客户端从数据库中读数据时，能够在主正本或者从正本上执行查问。只有主正本才能够承受写申请，从正本都是只读的。

同步复制与异步复制

复制十分重要的一个设计选项是同步复制还是异步复制。对于关系数据库系统，同步或异步通常是一个可配置的选项。

如下图，网站用户须要更新首页的头像图片。其根本流程是，客户将更新申请发送给主节点，主节点接管到申请，接下来将数据更新转发给从节点。最初，由主节点来告诉客户更新实现。

从节点 1 的复制是同步的，即主节点需期待直到从节点 1 确认实现了写入，而后才会向用户报告实现，并且将最新的写入对其余客户端可见。而从节点 2 的复制是异步的：主节点发送完音讯之后立刻返回，不必期待从节点 2 的实现确认。

同步复制的长处是，一旦向用户确认，从节点能够明确保障实现了与主节点的更新同步，数据曾经处于最新版本。万一主节点产生故障，总是能够在从节点持续拜访最新数据。毛病则是，如果同步的从节点无奈实现确认（例如因为从节点产生解体，或者网络故障，或任何其余起因），写入就不能视为胜利。主节点会阻塞其后所有的写操作，直到同步正本确认实现。

因而，把所有从节点都配置为同步复制有些不切实际。因为这样的话，任何一个同步节点的中断都会导致整个零碎更新停滞不前。实际中，如果数据库启用了同步复制，通常意味着其中某一个从节点是同步的，而其余节点则是异步模式。万一同步的从节点变得不可用或性能降落，则将另一个异步的从节点晋升为同步模式。这样能够保障至多有两个节点（即主节点和一个同步从节点）领有最新的数据正本。这种配置有时也称为半同步。

主从复制还常常会被配置为全异步模式。此时如果主节点产生失败且不可复原，则所有尚未复制到从节点的写申请都会失落。这意味着即便向客户端确认了写操作，却无奈保证数据的长久化。但全异步配置的长处则是，不论从节点上数据如许滞后，主节点总是能够持续响应写申请，零碎的吞吐性能更好。

配置新的从节点

如果须要减少新的从节点，如何确保新的从节点和主节点保持数据统一呢？逻辑上的次要操作步骤如下:

1. 在某个工夫点对主节点的数据正本产生一个一致性快照，这样防止长时间锁定整个数据库。
2. 将此快照拷贝到新的从节点。
3. 从节点连贯到主节点并申请快照点之后所产生的数据更改日志。因为在第一步创立快照时，快照与零碎复制日志的某个确定地位相关联，这个地位信息在不同的零碎有不同的称说，如 MySQL 将其称为“binlog coordinates”。
4. 取得日志之后，从节点来利用这些快照点之后所有数据变更，这个过程称之为追赶。接下来，它能够失常解决主节点上新的数据变动。

解决节点生效

从节点生效：追赶式复原

从节点的本地磁盘上都保留了正本收到的数据变更日志。如果从节点产生解体，而后顺利重启，或者主从节点之间的网络产生临时中断（闪断），则复原比拟容易，依据正本的复制日志，从节点能够晓得在产生故障之前所解决的最初一笔事务，而后连贯到主节点，并申请自那笔事务之后中断期间内所有的数据变更。在收到这些数据变更日志之后，将其利用到本地来追赶主节点。之后就和失常状况一样继续接管来自主节点数据流的变动。

主节点生效：节点切换

解决主节点故障的状况则比拟辣手：抉择某个从节点将其晋升为主节点；客户端也须要更新，这样之后的写申请会发送给新的主节点，而后其余从节点要承受来自新的主节点上的变更数据，这一过程称之为切换。

故障切换能够手动进行，或者以主动形式进行。主动切换的步骤通常如下:

1. 确认主节点生效。有很多种出错可能性，所以大多数零碎都采纳了基于超时的机制：节点间频繁地相互产生发送心跳存活音讯，如果发现某一个节点在一段比拟长时间内（例如 30s）没有响应，即认为该节点产生生效。
2. 选举新的主节点。能够通过选举的形式（超过少数的节点达成共识）来选举新的主节点，或者由之前选定的某管制节点来指定新的主节点。候选节点最好与原主节点的数据差别最小，这样能够最小化数据失落的危险。
3. 重新配置零碎使新主节点失效。客户端当初须要将写申请发送给新的主节点。如果原主节点之后从新上线，这时零碎要确保原主节点降级为从节点，并认可新的主节点。

然而，上述切换过程仍然充斥了很多变数：

• 如果应用了异步复制，且生效之前，新的主节点并未收到原主节点的所有数据；在选举之后，原主节点很快又从新上线并退出到集群，接下来新的主节点很可能会收到抵触的写申请。这是因为原主节点未意识的角色变动，还会尝试同步其余从节点，但其中的一个当初曾经接管成为现任主节点。常见的解决方案是，原主节点上未实现复制的写申请就此抛弃，但这可能会违反数据更新长久化的承诺。
• 如果在数据库之外有其余零碎依赖于数据库的内容并在一起协同应用，抛弃数据的计划就特地危险。例如，在 GitHub 的一个事变中，某个数据并非齐全同步的 MySQL 从节点被晋升为主正本，数据库应用了自增计数器将主键调配给新创建的行，然而因为新的主节点计数器落后于原主节点，它从新应用了已被原主节点调配进来的某些主键，而恰好这些主键已被内部 Redis 所援用，后果呈现 MySQL 和 Redis 之间的不统一。
• 在某些故障状况下，可能会产生两个节点同时都自认为是主节点。这种状况被称为脑裂，它十分危险：两个主节点都可能承受写申请，并且没有很好解决抵触的方法，最初数据可能会失落或者毁坏。作为一种平安应急计划，有些零碎会采取措施来强制敞开其中一个节点。然而，如果设计或者实现考虑不周，可能会呈现两个节点都被敞开的状况。
• 如何设置适合的超时来检测主节点生效？主节点生效后，超时工夫设置得越长也意味着总体复原工夫就越长。但如果超时设置太短，可能会导致很多不必要的切换。例如，突发的负载峰值会导致节点的响应工夫变长甚至超时，或者因为网络故障导致提早减少。如果零碎此时曾经处于高负载压力或网络曾经呈现重大拥塞，不必要的切换操作只会使总体状况变得更糟。

对于这些问题没有简略的解决方案。因而，即便零碎可能反对主动故障切换，有些运维团队依然更违心以手动形式来管制整个切换过程。

复制日志的实现

基于语句的复制

主节点记录所执行的每个写申请（操作语句）并将该操作语句作为日志发送给从节点。对于关系数据库，这意味着每个 INSERT、UPDATE 或 DELETE 语句都会转发给从节点，并且每个从节点都会剖析并执行这些 SQL 语句，如同它们是来自客户端那样。

但这种复制形式有一些不实用的场景:

• 任何调用非确定性函数的语句，如 NOW()获取以后工夫，或 RAND()获取一个随机数等，可能会在不同的正本上产生不同的值。
• 如果语句中应用了自增列，或者依赖于数据库的现有数据（例如，UPDATE …WHERE< 某些条件 >），则所有正本必须依照完全相同的程序执行，否则可能会带来不同的后果。进而，如果有多个同时并发执行的事务时，会有很大的限度。
• 有副作用的语句（例如，触发器、存储过程、用户定义的函数等），可能会在每个正本上产生不同的副作用。

基于预写日志传输

无论是日志构造的存储引擎，还是 B -tree 构造的存储引擎，所有对数据库写入的字节序列都被记入日志。因而能够应用完全相同的日志在另一个节点上构建正本：除了将日志写入磁盘之外，主节点还能够通过网络将其发送给从节点。

从节点收到日志进行解决，建设和主节点内容完全相同的数据正本。其次要毛病是日志形容的数据后果十分底层：一个 WAL 蕴含了哪些磁盘块的哪些字节产生扭转，诸如此类的细节。这使得复制计划和存储引擎严密耦合。如果数据库的存储格局从一个版本改为另一个版本，那么零碎通常无奈反对主从节点上运行不同版本的软件。

基于行的逻辑日志复制

另一种办法是复制和存储引擎采纳不同的日志格局，这样复制与存储逻辑剥离。这种复制日志称为逻辑日志，以辨别物理存储引擎的数据表示。

关系数据库的逻辑日志通常是指一系列记录来形容数据表行级别的写申请:

• 对于行插入，日志蕴含所有相干列的新值。
• 对于行删除，日志里有足够的信息来惟一标识已删除的行，通常是靠主键，但如果表上没有定义主键，就须要记录所有列的旧值。
• 对于行更新，日志蕴含足够的信息来惟一标识更新的行，以及所有列的新值（或至多蕴含所有已更新列的新值）。

如果一条事务波及多行的批改，则会产生多个这样的日志记录，并在前面跟着一条记录，指出该事务曾经提交。MySQL 的二进制日志 binlog（当配置为基于行的复制时）应用该形式。

因为逻辑日志与存储引擎逻辑解耦，因而能够更容易地放弃向后兼容，从而使主从节点可能运行不同版本的软件甚至是不同的存储引擎。

复制滞后问题

主从复制要求所有写申请都经由主节点，而任何正本只能承受只读查问。在这种扩大体系下，只需增加更多的从正本，就能够进步读申请的服务吞吐量。然而，这种办法实际上只能用于异步复制，如果试图同步复制所有的从正本，则单个节点故障或网络中断将使整个零碎无奈写入。而且节点越多，产生故障的概率越高，所以齐全同步的配置事实中反而十分不牢靠。

如果一个利用正好从一个异步的从节点读取数据，而该正本落后于主节点，则利用可能会读到过期的信息。这会导致数据库中呈现显著的不统一，这种不统一只是一个临时的状态，如果进行写数据库，通过一段时间之后，从节点最终会赶上并与主节点保持一致。这种效应也被称为最终一致性。

总的来说，正本落后的水平实践上并没有下限。失常状况下，主节点和从节点上实现写操作之间的时间延迟（复制滞后）可能有余 1 秒，这样的滞后，在实践中通常不会导致太大影响。然而，如果零碎已靠近设计下限，或者网络存在问题，则滞后可能轻松减少到几秒甚至几分钟不等。

读本人的写

许多利用让用户提交一些数据，接下来查看他们本人所提交的内容。提交新数据须发送到主节点，然而当用户读取数据时，数据可能来自从节点。

对于异步复制存在这样一个问题，如图所示，用户在写入不久即查看数据，则新数据可能尚未达到从节点。对用户来讲，看起来仿佛是刚刚提交的数据失落了。

基于主从复制的零碎该如何实现写后读一致性呢？有多种可行的计划，以下例举一二：

• 如果用户拜访可能会被批改的内容，从主节点读取；否则，在从节点读取。这背地就要求有一些办法在理论执行查问之前，就曾经晓得内容是否可能会被批改。例如，社交网络上的用户首页信息通常只能由所有者编辑，而其他人无奈编辑。因而，这就造成一个简略的规定：总是从主节点读取用户本人的首页配置文件，而在从节点读取其余用户的配置文件。
• 如果利用的大部分内容都可能被所有用户批改，那么上述办法将不太无效，它会导致大部分内容都必须经由主节点，这就丢失了读操作的扩展性。此时须要其余计划来判断是否从主节点读取。例如，跟踪最近更新的工夫，如果更新后一分钟之内，则总是在主节点读取；并监控从节点的复制滞后水平，防止从那些滞后工夫超过一分钟的从节点读取。
• 客户端还能够记住最近更新时的工夫戳，并附带在读申请中，据此信息，零碎能够确保对该用户提供读服务时都应该至多蕴含了该工夫戳的更新。如果不够新，要么交由另一个副原本解决，要么期待直到正本接管到了最近的更新。工夫戳能够是逻辑工夫戳（例如用来批示写入程序的日志序列号）或理论零碎时钟（在这种状况下，时钟同步又成为一个关键点）。
• 如果正本散布在多数据中心（例如思考与用户的天文靠近，以及高可用性），状况会更简单些。必须先把申请路由到主节点所在的数据中心（该数据中心可能离用户很远）。

如果同一用户可能会从多个设施拜访数据，例如一个桌面 Web 浏览器和一个挪动端的利用，状况会变得更加简单。此时，要提供跨设施的写后读一致性，即如果用户在某个设施上输出了一些信息而后在另一台设施上查看，也应该看到刚刚所输出的内容。在这种状况下，还有一些须要思考的问题：

• 记住用户上次更新工夫戳的办法实现起来会比拟艰难，因为在一台设施上运行的代码齐全无奈晓得在其余设施上产生了什么。此时，元数据必须做到全局共享。
• 如果正本散布在多数据中心，无奈保障来自不同设施的连贯通过路由之后都达到同一个数据中心。例如，用户的台式计算机应用了家庭宽带连贯，而挪动设施则应用蜂窝数据网络，不同设施的网络连接线路可能齐全不同。如果计划要求必须从主节点读取，则首先须要想方法确保将来自不同设施的申请路由到同一个数据中心。

枯燥读

假设用户从不同正本进行了屡次读取，如图所示，用户刷新一个网页，读申请可能被随机路由到某个从节点。用户 2345 先后在两个从节点上执行了两次完全相同的查问（先是大量滞后的节点，而后是滞后很大的从节点），则很有可能呈现以下状况。第一个查问返回了最近用户 1234 所增加的评论，但第二个查问因为滞后的起因，还没有收到更新因此返回后果是空。

实现枯燥读的一种形式是，确保每个用户总是从固定的同一正本执行读取（而不同的用户能够从不同的正本读取）。例如，基于用户 ID 的哈希的办法而不是随机抉择正本。但如果该正本产生生效，则用户的查问必须从新路由到另一个正本。

前缀统一读

如果 Poons 学生与 Cake 夫人之间进行了如下对话：

Poons 学生：Cake 夫人，您能看到多远的将来？
Cake 夫人：通常约 10s，Poons 学生。

这两句话之间存在因果关系：Cake 夫人首先是听到了 Poons 学生的问题，而后再去答复该问题。

不过，Cake 夫人所说的话经验了短暂的滞后达到该从节点，但 Poons 学生所说的经验了更长的滞后才达到。对于观察者来说，仿佛在 Poon 学生提出问题之前，Cake 夫人就开始了答复问题。

这是分区（分片）数据库中呈现的一个非凡问题。如果数据库总是以雷同的程序写入，则读取总是看到统一的序列，不会产生这种反常。然而，在许多分布式数据库中，不同的分区独立运行，因而不存在全局写入程序。这就导致当用户从数据库中读数据时，可能会看到数据库的某局部旧值和另一部分新值。

一个解决方案是确保任何具备因果程序关系的写入都交给一个分区来实现，但该计划实在实现效率会大打折扣。当初有一些新的算法来显式地追踪事件因果关系。

多主节点复制

主从复制存在一个显著的毛病：零碎只有一个主节点，而所有写入都必须经由主节点。如果因为某种原因，例如与主节点之间的网络中断而导致主节点无奈连贯，主从复制计划就会影响所有的写入操作。

对主从复制模型进行天然的扩大，则能够配置多个主节点，每个主节点都能够承受写操作，前面复制的流程相似：解决写的每个主节点都必须将该数据更改转发到所有其余节点。这就是多主节点（也称为主 - 主，或被动 / 被动）复制。此时，每个主节点还同时表演其余主节点的从节点。

实用场景

多数据中心

为了容忍整个数据中心级别故障或者更靠近用户，能够把数据库的正本横跨多个数据中心。而如果应用惯例的基于主从的复制模型，主节点势必只能放在其中的某一个数据中心，而所有写申请都必须通过该数据中心。

有了多主节点复制模型，则能够在每个数据中心都配置主节点，如下图所示的根本架构。在每个数据中心内，采纳惯例的主从复制计划；而在数据中心之间，由各个数据中心的主节点来负责同其余数据中心的主节点进行数据的替换、更新。

在多数据中心环境下，部署单主节点的主从复制计划与多主复制计划之间的差别:

性能

对于主从复制，每个写申请都必须经由广域网传送至主节点所在的数据中心。这会大大增加写入提早，并根本偏离了采纳多数据中心的初衷（即就近拜访）。而 在多主节点模型中，每个写操作都能够在本地数据中心疾速响应，而后采纳异步复制形式将变动同步到其余数据中心。

容忍数据中心生效

对于主从复制，如果主节点所在的数据中心产生故障，必须切换至另一个数据中心，将其中的一个从节点被晋升为主节点。在多主节点模型中，每个数据中心则能够独立于其余数据中心持续运行，产生故障的数据中心在复原之后更新到最新状态。

容忍网络问题

数据中心之间的通信通常经由广域网，它往往不如数据中心内的本地网络牢靠。对于主从复制模型，因为写申请是同步操作，对数据中心之间的网络性能和稳定性等更加依赖。多主节点模型则通常采纳异步复制，能够更好地容忍此类问题，例如长期网络闪断不会障碍写申请最终胜利。

只管多主复制具备上述劣势，但也存在一个很大的毛病：不同的数据中心可能会同时批改雷同的数据，因此必须解决潜在的写抵触。

离线客户端操作

另一种多主复制比拟适宜的场景是，利用在与网络断开后还须要持续工作。每个设施都有一个充当主节点的本地数据库，而后在所有设施之间采纳异步形式同步这些多主节点上的正本，同步滞后可能是几小时或者数天，具体工夫取决于设施何时能够再次联网。

从架构层面来看，上述设置基本上等同于数据中心之间的多主复制，只不过是个极其状况，即一个设施就是数据中心，而且它们之间的网络连接十分不牢靠。

合作编辑

咱们通常不会将合作编辑齐全等价于数据库复制问题，但二者的确有很多相似之处。当一个用户编辑文档时，所做的更改会立刻利用到本地正本（Web 浏览器或客户端应用程序），而后异步复制到服务器以及编辑同一文档的其余用户。

解决写抵触

同步与异步冲突检测

如果是主从复制数据库，第二个写申请要么会被阻塞直到第一个写实现，要么被停止。然而在多主节点的复制模型下，这两个写申请都是胜利的，并且只能在稍后的工夫点上能力异步检测到抵触，那时再要求用户层来解决抵触为时已晚。

实践上，也能够做到同步冲突检测，即期待写申请实现对所有正本的同步，而后再告诉用户写入胜利。然而，这样做将会失去多主节点的次要劣势：容许每个主节点独立承受写申请。如果的确想要同步形式冲突检测，或者应该思考采纳单主节点的主从复制模型。

防止抵触

解决抵触最现实的策略是防止发生冲突，即如果应用层能够保障对特定记录的写申请总是通过同一个主节点，这样就不会产生写抵触。事实中，因为不少多主节点复制模型所实现的抵触解决方案存在瑕疵，因而，防止抵触反而成为大家广泛举荐的首选计划。

例如，一个利用零碎中，用户须要更新本人的数据，那么咱们确保特定用户的更新申请总是路由到特定的数据中心，并在该数据中心的主节点上进行读 / 写。不同的用户则可能对应不同的主数据中心（例如依据用户的地理位置来抉择）。从用户的角度来看，这根本等价于主从复制模型。

然而，有时可能须要扭转当时指定的主节点，例如因为该数据中心产生故障，不得不将流量从新路由到其余数据中心，或者是因为用户曾经漫游到另一个地位，因此更凑近新数据中心。此时，抵触防止形式不再无效，必须有措施来解决同时写入抵触的可能性。

收敛于统一状态

如果每个正本都只是依照它所看到写入的程序执行，那么数据库最终将处于不统一状态。这相对是不可承受的，所有的复制模型至多应该确保数据在所有正本中最终状态肯定是统一的。因而，数据库必须以一种收敛趋同的形式来解决抵触，实现收敛的抵触解决有以下可能的形式:

• 给每个写入调配惟一的 ID，例如，一个工夫戳，一个足够长的随机数，一个 UUID 或者一个基于键 - 值的哈希，筛选最高 ID 的写入作为胜利者，并将其余写入抛弃。如果基于工夫戳，这种技术被称为最初写入者获胜。尽管这种办法很风行，然而很容易造成数据失落。
• 为每个正本调配一个惟一的 ID，并制订规定，例如序号高的正本写入始终优先于序号低的正本。这种办法也可能会导致数据失落。
• 以某种形式将这些值合并在一起。例如，按字母程序排序，而后拼接在一起。
• 利用预约义好的格局来记录和保留抵触相干的所有信息，而后依附应用层的逻辑，预先解决抵触（可能会提醒用户）。

自定义抵触解决逻辑

解决抵触最合适的形式可能还是依附应用层，所以大多数多主节点复制模型都有工具来让用户编写利用代码来解决抵触。能够在写入时或在读取时执行这些代码逻辑：

• 在写入时执行：只有数据库系统在复制变更日志时检测到抵触，就会调用应用层的抵触处理程序。
• 在读取时执行：当检测到抵触时，所有抵触写入值都会临时保留下来。下一次读取数据时，会将数据的多个版本读返回给应用层。应用层可能会提醒用户或主动解决抵触，并将最初的后果返回到数据库。

抵触解决通常用于单个行或文档，而不是整个事务。如果有一个原子事务蕴含多个不同写申请，每个写申请依然是离开思考来解决抵触。

什么是抵触？

有些抵触是不言而喻的。两个写操作同时批改同一个记录中的同一个字段，并将其设置为不同的值。毫无疑问，这就是一个抵触。

而其余类型的抵触可能会十分奥妙，更难以发现。例如一个会议室预订零碎，它次要记录哪个房间由哪个人在哪个时间段所预订。这个应用程序须要确保每个房间只能有一组人同时预约（即不得有雷同房间的反复预订）。如果为同一个房间创立两个不同的预订，可能会发生冲突。只管利用在预订时会查看房间是否可用，但如果两个预订是在两个不同的主节点上进行，则还是存在抵触的可能。

拓扑构造

如果存在两个以上的主节点，会有多个可能的同步拓扑构造，如图所示：

最常见的拓扑构造是全副 - 至 - 全副，每个主节点将其写入同步到其余所有主节点。而其余一些拓扑构造也有广泛应用，例如，默认状况下 MySQL 只反对环形拓扑构造，其中的每个节点接管来自前序节点的写入，并将这些写入（加上本人的写入）转发给后序节点。另一种风行的拓扑是星形构造：一个指定的根节点将写入转发给所有其余节点。星形拓扑还能够推广到树状构造。

在环形和星形拓扑中，写申请须要通过多个节点能力达到所有的正本，即两头节点须要转发从其余节点收到的数据变更。为避免有限循环，每个节点须要赋予一个惟一的标识符，在复制日志中的每个写申请都标记了已通过的节点标识符。如果某个节点收到了蕴含本身标识符的数据更改，表明该申请曾经被解决过，因而会疏忽此变更申请，防止反复转发。

环形和星形拓扑的问题是，如果某一个节点产生了故障，在修复之前，会影响其余节点之间复制日志的转发。能够采纳重新配置拓扑构造的办法临时排除掉故障节点。在大多数部署中，这种重新配置必须手动实现。而对于链接更密集的拓扑（如全副到全副），音讯能够沿着不同的门路流传，防止了单点故障，因此有更好的容错性。但另一方面，全链接拓扑也存在一些本身的问题。次要是存在某些网络链路比其余链路更快的状况（例如因为不同网络拥塞），从而导致复制日志之间的笼罩，如下图所示。

无主节点复制

一些数据存储系统则采纳了不同的设计思路：抉择放弃主节点，容许任何正本间接承受来自客户端的写申请。

对于某些无主节点零碎实现，客户端间接将其写申请发送到多正本，而在其余一些实现中，由一个协调者节点代表客户端进行写入，但与主节点的数据库不同，协调者并不负责写入程序的保护。

节点生效时写入数据库

假如一个三正本数据库，其中一个正本以后不可用。在基于主节点复制模型下，如果要持续解决写操作，则须要执行切换操作。

对于无主节点配置，则不存在这样的切换操作。用户将写申请并行发送到三个正本，有两个可用正本承受写申请，而不可用的正本无奈解决该写申请。如果假设三个正本中有两个胜利确认写操作，用户收到两个确认的回复之后，即可认为写入胜利。客户齐全能够疏忽其中一个正本无奈写入的状况。

生效的节点之后从新上线，而客户端又开始从中读取内容。因为节点生效期间产生的任何写入在该节点上都尚未同步，因而读取可能会失去过期的数据。

为了解决这个问题，当一个客户端从数据库中读取数据时，它不是向一个正本发送申请，而是并行地发送到多个正本。客户端可能会失去不同节点的不同响应，包含某些节点的新值和某些节点的旧值。能够采纳版本号技术确定哪个值更新。

读修复与反熵

读修复

当客户端并行读取多个正本时，能够检测到过期的返回值。用户从正本 3 取得的是版本 6，而从正本 1 和 2 失去的是版本 7。客户端能够判断正本 3 是一个过期值，而后将新值写入到该正本。这种办法次要适宜那些被频繁读取的场景。

反嫡过程

一些数据存储有后盾过程一直查找正本之间数据的差别，将任何短少的数据从一个正本复制到另一个正本。与基于主节点复制的复制日志不同，此反嫡过程并不保障以特定的程序复制写入，并且会引入显著的同步滞后。

读写 quorum

咱们晓得，胜利的写操作要求三个正本中至多两个实现，这意味着至少有一个正本可能蕴含旧值。因而，在读取时须要至多向两个正本发动读申请，通过版本号能够确定肯定至多有一个蕴含新值。如果第三个正本呈现停机或响应迟缓，则读取仍能够持续并返回最新值。

把上述情理推广到个别状况，如果有 n 个正本，写入须要 w 个节点确认，读取必须至多查问 r 个节点，则只有 w + r > n，读取的节点中肯定会蕴含最新值。例如在后面的例子中，n = 3，w = 2，r = 2。满足上述这些 r、w 值的读 / 写操作称之为法定票数读（或仲裁读）或法定票数写（或仲裁写）。也能够认为 r 和 w 是用于断定读、写是否无效的最低票数。

参数 n、w 和 r 通常是可配置的，一个常见的抉择是设置 n 为某奇数（通常为 3 或 5），w = r = (n + 1) / 2（向上舍入）。也能够依据本人的需要灵便调整这些配置。例如，对于读多写少的负载，设置 w = n 和 r = 1 比拟适合，这样读取速度更快，然而一个生效的节点就会使得数据库所有写入因无奈实现 quorum 而失败。

Quorum 一致性的局限性

通常，设定 r 和 w 为简略少数（多于 n / 2）节点，即可确保 w + r > n，且同时容忍多达 n / 2 个节点故障。然而，quorum 不肯定非得是少数，读和写的节点集中有一个重叠的节点才是最要害的。

也能够将 w 和 r 设置为较小的数字，从而让 w + r <= n。此时，读取和写入操作仍会被发送到 n 个节点，但只需期待更少的节点回应即可返回。

因为 w 和 r 配置的节点数较小，读取申请当中可能恰好没有蕴含新值的节点，因而最终可能会返回一个过期的旧值。好的一方面是，这种配置能够取得更低的提早和更高的可用性，例如网络中断，许多正本变得无法访问，相比而言有更高的概率持续解决读取和写入。只有当可用的正本数曾经低于 w 或 r 时，数据库才会变得无奈读 / 写，即处于不可用状态。

即便在 w + r > n 的状况下，也可能存在返回旧值的边界条件。这次要取决于具体实现，可能的状况包含：

• 如果采纳了 sloppy quorum（参阅前面的“宽松的 quorum 与数据回传”），写操作的 w 节点和读取的 r 节点可能齐全不同，因而无奈保障读写申请肯定存在重叠的节点。
• 如果两个写操作同时产生，则无奈明确先后顺序。这种状况下，惟一平安的解决方案是合并并发写入（参见后面的“解决写抵触”）。如果依据工夫戳筛选胜者，则因为时钟偏差问题，某些写入可能会被谬误地摈弃。
• 如果写操作与读操作同时产生，写操作可能仅在一部分正本上实现。此时，读取时返回旧值还是新值存在不确定性。
• 如果某些正本上曾经写入胜利，而其余一些正本产生写入失败（例如磁盘已满），且总的胜利正本数少于 w，那些已胜利的正本上不会做回滚。这意味着只管这样的写操作被视为失败，后续的读操作仍可能返回新值。
• 如果具备新值的节点起初产生生效，但复原数据来自某个旧值，则总的新值正本数会低于 w，这就突破了之前的断定条件。
• 即便所有工作失常，也会呈现一些边界状况，如一致性与共识中所介绍的“可线性化与 quorum”。

倡议最好不要把参数 w 和 r 视为相对的保障，而是一种灵便可调的读取新值的概率。

这里通常无奈失去后面的“复制滞后问题”中所列举的一致性保障，包含写后读、枯燥读、前缀统一读等，因而后面探讨种种异样同样会产生在这里。如果的确须要更强的保障，须要思考事务与共识问题。

宽松的 quorum 与数据回传

quorum 并不总如期待的那样提供高容错能力。一个网络中断能够很容易切断一个客户端到少数数据库节点的连贯。只管这些集群节点是活着的，而且其余客户端也的确能够失常连贯，然而对于断掉连贯的客户端来讲，状况无疑等价于集群整体失效。这种状况下，很可能无奈满足最低的 w 和 r 所要求的节点数，因而导致客户端无奈满足 quorum 要求。

在一个大规模集群中（节点数远大于 n 个），客户可能在网络中断期间还能连贯到某些数据库节点，但这些节点又不是可能满足数据仲裁的那些节点。此时，咱们是否应该承受该写申请，只是将它们临时写入一些可拜访的节点中？（这些节点并不在 n 个节点汇合中）。
这称之为宽松的仲裁：写入和读取依然须要 w 和 r 个胜利的响应，但蕴含了那些并不在先前指定的 n 个节点。

一旦网络问题失去解决，长期节点须要把接管到的写入全副发送到原始主节点上。这就是所谓的数据回传。

能够看出，sloppy quorum 对于进步写入可用性特地有用：要有任何 w 个节点可用，数据库就能够承受新的写入。然而这意味着，即便满足 w + r > n，也不能保障在读取某个键时，肯定能读到最新值，因为新值可能被长期写入 n 之外的某些节点且尚未回传过去。