NoSQL Peer-to-Peer Replication 对等复制

翻译内容:

NoSQL Distilled 第四章 Distribution Models

作者简介:

本节摘要:

今天我们主要讨论有关分布模型中复制(Replication)的内容,今天的内容主要说对等复制(Peer-to-Peer Replication)。复制在分布式存储中是一个很重要的内容,知道了有关复制及分片,你也就知道了分布式存储的底层原理。

4.4. Peer-to-Peer Replication 对等复制

Master-slave replication helps with read scalability but doesn’t help with scalability of writes. It provides resilience against failure of a slave, but not of a master. Essentially, the master is still a bottleneck and a single point of failure. Peer-to-peer replication (see Figure 4.3) attacks these problems by not having a master. All the replicas have equal weight, they can all accept writes, and the loss of any of them doesn’t prevent access to the data store.

主从复制帮助我们提高了读取操作的故障恢复能力。然后并没有提高写入能力的扩展性(译者曰:意思就是读取现在有多个节点,但写入还是只有一个节点来处理)。主从复制提供的这种故障恢复能力只有在从节点出现问题的时候,才能体现出来,并不能解决主节点出现问题的恢复。(译者曰:这句话有点绕,他说的其实就是读的扩展有了,但写的扩展还没有,因为写还是必须经过master,然后同步到slave)。所以呢,主节点(master)依然是一个瓶颈,依然是一个单点(a single point of failure)。对等复制(Peer-to-peer replication)就是为解决这个问题而生的。因为他没有master一说,没有主从一说。所有的副本(replicas)的权重都是一样的,地位是相同的,他们都可以接受写操作并且丢失了一个并不会影响数据的读取。(译者曰:也有小伙伴们称之为:masterless模式)

Figure 4.3. Peer-to-peer replication has all nodes applying reads and writes to all the data.

图 4.3 对等复制的所有的节点都可以接受写和读操作。

The prospect here looks mighty fine. With a peer-to-peer replication cluster, you can ride over node failures without losing access to data. Furthermore, you can easily add nodes to improve your performance. There’s much to like here—but there are complications.

上面描述的画面也许看起来不错。在集群上使用“对等复制”方案时,你可以轻松的驾驭(ride:骑在各个节点上,是不是有点污)节点故障,而不至于数据无法访问。更重要的是,你可以轻松增加节点来改善和提高性能。她有很多可爱之处,但也有一些问题存在。

The biggest complication is, again, consistency. When you can write to two different places, you run the risk that two people will attempt to update the same record at the same time—a write-write conflict. Inconsistencies on read lead to problems but at least they are relatively transient. Inconsistent writes are forever.

一个最大的问题就是,老生常谈的问题:一致性。当可以写到两个地方的时候,如果有两个人在同一时间内尝试更新同一个纪录,这时候就会出现叫做“write-write”冲突。(译者曰:这可是个大问题啊) 在读取操作上的不一致至少还是短暂的。但写入操作的不一致是永远的。

We’ll talk more about how to deal with write inconsistencies later on, but for the moment we’ll note a couple of broad options. At one end, we can ensure that whenever we write data, the replicas coordinate to ensure we avoid a conflict. This can give us just as strong a guarantee as a master, albeit at the cost of network traffic to coordinate the writes. We don’t need all the replicas to agree on the write, just a majority, so we can still survive losing a minority of the replica nodes.

我们将会在之后的章节来讨论如何解决“写不一致”的问题,不过我们只需要知道两种大致的做法就可以了。一种就是,不论何时写数据,我们都让那些副本们进行相互的协调,来避免冲突。这就好比主从复制时候的master一样。(译者曰:对等复制只需要加个协调动作,便和主从复制一样把写入冲突给解决了。)尽管协调这件事情需要花费一些网络的流量。在写入的时候我们不需要所有的副本都同意,只需要大部分同意就行了,这样就算丢失了副本节点的一小部分,数据库还是能用。

At the other extreme, we can decide to cope with an inconsistent write. There are contexts when we can come up with policy to merge inconsistent writes. In this case we can get the full performance benefit of writing to any replica.

另外一种极端方案就是,设法去处理这些不一致的写入操作。怎么处理呢?我们可以按照某种策略来合并这些不一致的写入操作。(译者曰:就像git处理冲突那一样,通过merge来搞,你暂时可以这样理解)在这种情况下,任何副本节点都能写入数据,这自然就提高了性能啊。

These points are at the ends of a spectrum where we trade off consistency for availability.

当我们权衡一致性和可用性的时候,上面这两个方案处于两个极端,一个是写入之前必须要解决冲突,一个是完全不解决,随便写,之后merge。(译者曰:其实就是说你要求无限的一致性的时候,性能就会下降;你要求无限的性能的时候,无限一致性自然不能保障)


附:几个文中的单词

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

原文发表时间:2016-04-26

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT技术精选文摘

当代码变更遇上精准测试的总结

敏捷模式下迭代频繁,回归测试时总是不知道变动的范围。Devlop 有的时候也不知道他改了哪些东西,影响到哪些节点,或者是很多人改的,彼此不知道。遇到有代码洁癖的...

17650
来自专栏大数据架构

超大规模 Spark 集群灰度发布 CI CD

目前主流的代码管理工具有,Github、Gitlab等。本文所介绍的内容中,所有代码均托管于私有的 Gitlab 中。

25930
来自专栏杨建荣的学习笔记

时间序列数据库InfluxDB初探(r12笔记第74天)

性能监控中的很多数据都是根据时间维度来生成的,就算是很少的几台服务器,如果设置了大量的监控项,每天的数据量也是很客观的,再加上是成千上万的服务器,这个量级就...

35370
来自专栏web前端教室

第七节,生成商品类型、广告条--《vue+vant+node+mongoDB+koa2》电商项目实战连载

视频有些模糊,这个目前我也没有办法,因为我没有微信公众号的视频的高级权限,所以这里只能是先搞成这样。清晰视频的获取办法,在文章结尾有写到,同学们可以自行获取。

21230
来自专栏Android机动车

Google 最新模拟器重磅来袭!秒开并还原到之前工作状态!

12月18日,Google 官方Quick Boot博客的发布,给我们带来了最新的Android模拟器,其中最突出的特点技术 快速启动。声称可以在 6 秒之内便...

41620
来自专栏恰童鞋骚年

谈谈对于企业级系统架构的理解

在我们刚开始学习架构的时候,首先会想到分层的概念,分层架构比较经典的是三层架构,那么,什么是三层架构呢?它包括表现层,业务层,数据访问层;而对于一个新手来说,从...

14520
来自专栏纯洁的微笑

微服务架构—服务降级

什么是服务降级?当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或...

22620
来自专栏前端知识分享

第143天:渐进增强和优雅降级之间的不同

第一个例子的写法叫做渐进增强(progressive enhancement),第二个例子的写法叫做优雅降级(graceful degradation)。(关于...

11520
来自专栏数据和云

创新,才能不被淘汰-机器学习时代,运维将何去何从?

我们曾经分享过一篇文章,云时代的DBA,何去何从?,在文中我们讨论了Oracle最近几年重点转而向云的变革,它全力以赴在做的一件事情就是把所有的产品和服务转移到...

28960
来自专栏机器学习算法与Python学习

给Python初学者:如何用 Django 写一个36Kr

关键字全网搜索最新排名 【机器学习算法】:排名第一 【机器学习】:排名第二 【Python】:排名第三 【算法】:排名第四 首先需要说明一下,这篇教程是写给初学...

37570

扫码关注云+社区

领取腾讯云代金券