NoSQL-Quorums-仲裁

作者简介:

当你权衡“一致性”或“持久性”的时候,不是一个非此即彼,非黑即白的过程。一个请求中涉及的节点越多,那么我们越有可能避免不一致。这自然就引发了一个问题:需要多少个节点才能保证强一致性?

5.5. Quorums 仲裁

当你权衡“一致性”或“持久性”的时候,不是一个非此即彼,非黑即白的过程。一个请求中涉及的节点越多,那么我们越有可能避免不一致。这自然就引发了一个问题:需要多少个节点才能保证强一致性?

现在假设一份数据需要复制到三个节点中。你不需要所有的节点都确认写入操作来保证强一致性,你只需要其中的两个节点确认了写入操作就可以了,也就是大多数。如果出现冲突的写入,只需要得到大多数的认可(也就是超过半数)。这个做法我们称作“写入仲裁”(write quorum),我们也可以用一个稍微做作的不等式来表示就是:W > N/2,什么意思呢?就是参与到写入操作的节点数量必须要多于涉及到复制的节点数量(N)的一半。副本(replicas)的数量通常又被称作“复制因子”(replication factor)。

写入仲裁(write quorum)相似的是读取仲裁(read quorum)的概念:就是你和多少个节点联系确保了你能获得最新的数据。读取仲裁更复杂一点,因为这依赖于多少个节点需要确认一个写入。

现在我们就分析下复制因子为3的情况。如果所有的写入需要两个节点来确认(W = 2) ,那么我们需要联系至少两个节点来确保我们能获得最新的数据。但,如果,写入只是被一个节点确认(W = 1),我们就需要和所有的三个节点进行通话来确保我们可以获得最新的更新。在这种情况下,由于我们没进行写入仲裁,我们也许就会遭遇更新冲突,但只要从足够多的节点中读出数据,我们依然可以侦测出此类冲突。这样我们就可以得到强一致的读取即使我们在写入上没有强一致。

执行读取操作时所需联系的节点数(R),确认写入操作时所需要征询的节点数(W),以及复制因子(N)这三者之间的关系,可以用一个不等式来表示。那就是,只有当R + W > N时,才能保证读取操作的强一致性。

上面说的这些不等式都适用于“对等式分布模型”。如果我们使用“主从分布模型”,那么只需要向主节点中写入数据,这样就可以避免“写写冲突”(write-write conflicts)。同样的,只需要从主节点读取就可以避免“读写冲突”(ead- write conflicts)。在这种情况下,往往很容易就把集群的节点数与复制因子相混淆,傻傻分不清楚,然而他们是两个概念。比如,我可以有一个100个节点的集群,但复制因子却只有3,因为大部分数据都分布在各个“分片”之中。

事实上,很多权威都建议说复制因子为3就足够拥有不错的“故障恢复能力”(resilience)了。这时,如果只有一个节点出错,那么仍然能够满足读取和写入所需要的最小的法定节点数。如果有自动均衡机制(automatic rebalancing),那么用不了好久,集群就会自动创建一个“第三”副本,所以,在替代副本建立好之前,丢失掉“第二”副本的概率是很低的。

参与某个操作的节点数,可能会随着该操作的具体情况而改变。当我们写入数据时,根据“一致性”与“可用性”这两个因素的重要程度,有一些更新操作可能需要获得足够的节点的支持率才能执行,而另外一些则不需要。与之相似,某些读取操作可能更看重执行速度,而可以容忍过期数据,此时它就可以少联系几个节点。

通常你需要将这两方面都考虑进来。如果你希望访问速度够快同时还必须保证强一致性,那么写入操作就要得到所有的节点的确认才行,这样的话,只需要联系一个节点,就能完成读取操作了(N = 3, W = 3, R = 1)。这就意味着你的写入将会变得很慢,因为每次写入都 必须要和所有的三个节点联系,这种情况是不能容忍那怕一个节点出错。但在某些情况下,还是需要权衡一致性和可用性。

上面说了这么多,就是希望我们在“一致性”和“可用性”之间做出更好的权衡,“之间”是存在很多选项的,需要根据每个方案的优缺点最后选择一个适合自己的方案。有些NoSQL技术博客的作者认为一致性和可用性之间是一个简单的权衡。但我们希望在这里告诉你,让你意识到这两者间是有更灵活的选择和权衡,而不是简单的权衡,当然也更复杂一点。

原文发布于微信公众号 - ImportSource(importsource)

原文发表时间:2016-05-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏cloudskyme

基于java的分布式爬虫

分类 分布式网络爬虫包含多个爬虫,每个爬虫需要完成的任务和单个的爬行器类似,它们从互联网上下载网页,并把网页保存在本地的磁盘,从中抽取URL并沿着这些URL的指...

4317
来自专栏星流全栈

React + Redux 最佳实践

2835
来自专栏iOSDevLog

Google Colab免费GPU教程

现在,你可以开发深度学习与应用谷歌Colaboratory -on的免费特斯拉K80 GPU -使用Keras,Tensorflow和PyTorch。

5065
来自专栏前端吧啦吧啦

项目版本与分支管理之阿里AoneFlow模式分析

2113
来自专栏IT派

Django | CoolBlog开发笔记第1课:项目分析

CoolBlog开发笔记第1课:项目分析 首先说一下CoolBlog开发笔记是我制作的《Django实战项目》系列教程基础篇的内容,使用Django来开发一个...

4004
来自专栏沈唁志

如何简单计算PHP网站是否已经最高负载

2355
来自专栏ImportSource

MartinFowler告诉你大数据架构师必备的NoSQL技能-版本戳(下)

上一集:MartinFowler告诉你大数据架构师必备的NoSQL技能-版本戳(上) 上集我们说了在single-server以及在“主从复制模型”(mast...

3799
来自专栏程序猿DD

Spring Cloud构建微服务架构:分布式服务跟踪(抽样收集)【Dalston版】

通过 TraceID和 SpanID已经实现了对分布式系统中的请求跟踪,而这些记录的跟踪信息最终会被分析系统收集起来,并用来实现对分布式系统的监控和分析功能,比...

3476
来自专栏玄魂工作室

CTF实战19 渗透测试-主机信息探测

其原理是不同厂家的IP协议栈实现之间存在许多细微的差别,通过这些差别就能对目标系统的操作系统加以猜测

1311
来自专栏IMWeb前端团队

后台:nodejs 前台:vue 全栈开发 外卖平台系统

关于 一直考虑写一个功能齐全的完整Nodejs项目,但苦于没有找到合适的类型,而且后台系统无法直观的感受到,需要有一个前台项目配合,因此迟迟没有动笔。恰好前一段...

3420

扫码关注云+社区

领取腾讯云代金券