无主复制系统(3)-Quorum一致性的局限性

简介: 若有n个副本,且配置w和r,使得w + r > n w + r> nw+r>n,期望可以读到一个最新值。因为成功写入的节点集合和读取的节点集合必有重合,这样读取的节点中至少有一个具有最新值,如图-11。

若有n个副本,且配置w和r,使得w + r > n w + r> nw+r>n,期望可以读到一个最新值。因为成功写入的节点集合和读取的节点集合必有重合,这样读取的节点中至少有一个具有最新值,如图-11。


一般设定r和w为简单多数(超过n/2)节点,即可确保 w + r> n,且同时容忍多达 n/2 个节点故障。但是,法定人数不一定必须是大多数,只是读写使用的节点交集至少需要包括一个节点。其他法定人数的配置是可能的,这使得分布式算法的设计有一定的灵活性。


您也可以将w和r设置为较小的数字,以使w + r ≤ n w + r≤nw+r≤n(即法定条件不满足)。在这种情况下,读取和写入操作仍将被发送到n个节点,但操作成功只需要少量的成功响应。


较小的w和r更有可能会读取过时的数据,因为您的读取更有可能不包含具有最新值的节点。另一方面,这种配置允许更低的延迟和更高的可用性:如果存在网络中断,并且许多副本变得无法访问,则可以继续处理读取和写入的机会更大。只有当可达副本的数量低于w或r时,数据库才分别变得不可用于写入或读取。


但是,即使在w + r > n w + r> nw+r>n的情况下,也可能存在返回陈旧值的边缘情况。这取决于实现,但可能的情况包括:


若使用宽松的法定人数,w个写入和r个读取落在完全不同的节点上,因此r节点和w之间不再保证有重叠节点【46】。

如果两个写入同时发生,不清楚哪一个先发生。在这种情况下,唯一安全的解决方案是合并并发写入(参阅处理写入冲突)。如果根据时间戳(最后写入胜利)挑选出一个胜者,则由于时钟偏差[35],写入可能会丢失

如果写操作与读操作同时发生,写操作可能仅反映在某些副本上。在这种情况下,不确定读取是返回旧值还是新值。

如果写操作在某些副本上成功,而在其他节点上失败(例如,因为某些节点上的磁盘已满),在小于w个副本上写入成功。所以整体判定写入失败,但整体写入失败并没有在写入成功的副本上回滚。这意味着如果一个写入虽然报告失败,后续的读取仍然可能会读取这次失败写入的值【47】。

如果携带新值的节点失败,需要读取其他带有旧值的副本。并且其数据从带有旧值的副本中恢复,则存储新值的副本数可能会低于w,从而打破法定人数条件。

即使一切工作正常,有时也会不幸地出现关于时序(timing) 的边缘情况

因此,尽管法定人数似乎保证读取返回最新的写入值,但在实践中并不那么简单。 Dynamo风格的数据库通常针对可以忍受最终一致性的用例进行优化。允许通过参数w和r来调整读取陈旧值的概率,但把它们当成绝对的保证是不明智的。


尤其是,因为通常没有得到“复制延迟问题”中讨论的保证(读己之写,单调读,一致前缀读),前面提到的异常可能会发生在应用程序中。更强有力的保证通常需要事务或共识。我们将在第七章和第九章回到这些话题。


4.2.1 监控旧值

运维角度,监视DB是否返回最新结果很重要。即使应用能容忍读旧值,也需了解复制的当前运行状况。若明显滞后,就是信号,需排查原因(如网络问题或节点超负荷)。


主从复制系统,DB通常会导出复制滞后的度量标准,可将其集成到监控系统。因为主、从节点的写都遵从相同顺序,而每个节点都维护了复制日志执行的当前偏移量。 通过对比主、从节点当前偏移值,即可衡量该从节点落后主节点程度。


无主复制系统,无固定写入顺序,因而监控也更难。且若数据库只使用读修复(无反熵过程),那么旧值的落后就无上限。例如若一个值很少被访问,则返回的旧值可能很老了!


衡量无主复制数据库的研究,根据参数n,w和r来预测旧值读取的预期百分比。不幸的是,这还不是常见做法,但将旧测量值包含在数据库的度量标准集中是好趋势。最终一致性是很模糊的保证,可操作性角度,能量化“最终”很有价值。

目录
相关文章
|
6月前
|
图形学
计算机辅助设计的基本原理与应用 - 副本
计算机辅助设计的基本原理与应用 - 副本
|
存储 缓存 算法
ES写入过程和写入原理调优及如何保证数据的写一致性(上)
ES写入过程和写入原理调优及如何保证数据的写一致性
ES写入过程和写入原理调优及如何保证数据的写一致性(上)
|
1月前
|
消息中间件 SQL 分布式计算
大数据-74 Kafka 高级特性 稳定性 - 控制器、可靠性 副本复制、失效副本、副本滞后 多图一篇详解
大数据-74 Kafka 高级特性 稳定性 - 控制器、可靠性 副本复制、失效副本、副本滞后 多图一篇详解
21 2
|
6月前
|
存储 监控 负载均衡
保证Redis的高可用性是一个涉及多个层面的任务,主要包括数据持久化、复制与故障转移、集群化部署等方面
【5月更文挑战第15天】保证Redis高可用性涉及数据持久化、复制与故障转移、集群化及优化策略。RDB和AOF是数据持久化方法,哨兵模式确保故障自动恢复。Redis Cluster实现分布式部署,提高负载均衡和容错性。其他措施包括身份认证、多线程、数据压缩和监控报警,以增强安全性和稳定性。通过综合配置与监控,可确保Redis服务的高效、可靠运行。
235 2
|
1月前
|
架构师 Java 数据中心
二阶段提交:确保分布式系统中数据一致性的关键协议
【10月更文挑战第16天】在分布式系统中,数据一致性的维护是一个至关重要的挑战。为了应对这一挑战,二阶段提交(Two-Phase Commit,简称2PC)协议应运而生。作为一种经典的分布式事务协议,2PC旨在确保在分布式系统中的所有节点在进行事务提交时保持一致性。
37 0
|
5月前
|
消息中间件 Kafka 程序员
Kafka面试必备:深度解析Replica副本的作用与机制
**Kafka的Replica副本是保证数据可靠性的关键机制。每个Partition有Leader和Follower副本,Leader处理读写请求及管理同步,Follower被动同步并准备成为新Leader。从Kafka 2.4开始,Follower在完全同步时也可提供读服务,提升性能。数据一致性通过高水位机制和Leader Epoch机制保证,后者更精确地判断和恢复数据一致性,增强系统容错能力。**
202 1
|
4月前
|
消息中间件 算法
分布式篇问题之“最终一致性”问题如何解决
分布式篇问题之“最终一致性”问题如何解决
|
6月前
|
前端开发 JavaScript 算法
分布式系统的一致性级别划分及Zookeeper一致性级别分析
分布式系统的一致性级别划分及Zookeeper一致性级别分析
|
6月前
|
监控 NoSQL Redis
RedisShake如何处理数据同步过程中的冲突和一致性问题
RedisShake保障数据同步一致性,支持全量和增量同步,处理并发冲突(利用乐观锁机制),并进行数据校验。遇到故障能自动恢复和重试,保证不间断同步。同时,提供监控和日志功能,便于识别和解决问题,确保数据完整性。
225 0