专栏首页鸿的学习笔记分布式系统下如何进行数据复制?(下)

分布式系统下如何进行数据复制?(下)

对于single-leader的数据复制模式,并且我们选择了异步的方式对数据进行处理。假如写入数据和读取数据都出现了并发的情况,显然数据会出现短时间不一致的情况,不过最后都会变成一致。但是这个短暂的时间差足以产生相当大的问题。主要可以分为三类:

  1. Reading Your Own Writes

想象一下,我在朋友圈发了一条动态,服务器在后端接受了数据,然后leader将数据拷贝到对应的follower上,由于发生了些许的网络延迟,数据只是拷贝到了follower1上,但是此时你刷新了朋友圈,希望能看到刚刚发出的动态,于是手机向服务器请求希望获得刚刚发出的动态,leader没有向follower1请求数据,而是向follower2请求数据,follower2还没有来的及接受到之前的写数据,follower2回复没有最新的数据,此时你的朋友圈再刷新的时候就会发现我刚刚发的消息去哪了?这就是你读不到你写入的数据了。

那么我们该如何解决呢?

首先我们可以从leader缓存刚好的数据,直接从leader读,或者是client记住最新的时间戳,leader读取数据时确保读到的数据是最新的时间戳。

  1. Monotonic Reads

这个情况类似于上述的例子,需要区别的是,我们在刷新朋友圈的时候,第一个请求恰巧发给了follower1,得到了刚好发出的动态,但是过了一会再刷新,请求给了follower2,这个是没有接收到最新的动态的,于是你崩溃了,怎么我再刷新一遍我刚好的数据就没有了呢?

这个的解决办法很简单,只要保证数据的请求每次都来源于同一个节点接好了。

  1. Consistent Prefix Reads

这个来源于因果性,还是讲例子吧。现在有一个对话,问:你叫啥名?答:小明。这个对话正在写入数据库,假设此时有个听众,他向数据库发送请求,由于网络延迟,后一个答先写入了,于是听众看到的数据就变成了小明/你叫啥名,显然违反了因果性。

解决办法需要数据库保证任何相关的写都是同时写入同一个节点。

在分析完single-leader的情况下,我们来看看multi-leader。我们很容易想到single-leader对于leader的要求太高了,所有的写都必须经过它,自身的压力也足够大,所以自然而然的想到了multi-leader。在现实生活中multi-leader也有着极为广泛的应用,例如多地分布的数据中心,协同编辑等等。当然我们很容易推理出来,single-leader遇上的麻烦,multi-leader也会遇上,除此之外,multi-leader还需要解决写冲突的问题。

什么是写冲突呢?在multi-leader的情况下,写数据的请求会分发到不同的leader上,假设有两个leader,leader1和leader2,leader1接收了一条请求要将x改为B,同时leader2接收的信息是x改A,那么数据库的数据x到底是A还是B呢?当我们想要解决这个写冲突时,那就必须一个coordinater先确定冲突,那么又回到了single-leader了。

既然无法从根本上解决,那就要根据具体情况具体分析了。对于多地的数据中心,数据的请求可以不需要经过分发,而是同一个user的请求只会进入到对应于它的数据中心。虽然这个有所缓解,但是依然存在一个问题,user移动了位置,那么对应的数据中心也发生了改变,还是要面临着如何解决写入冲突的问题。一般而言,有四种方式:1.使用唯一的ID(timestamp, a random number),选取数值最高的ID,这也就是著名的LWW,last writewins。2.给每一个副本一个唯一ID,选取最高ID的副本解决冲突3.将数据合并在一起,比如将前面的A,B变为A/B。4.直接将冲突的信息保存下来,稍后再解决,甚至直接抛给user去解决。上面四种方法也是要根据业务去选择如何解决写入冲突问题。

聊完multi-leader,最后看看leaderless。Leaderless replication最为出名的是亚马逊的Dynamo系统,这个系统影响了一大批leaderless的数据库,于是leaderless也被称为Dynamo-style。对于leaderless系统,可用性发挥到了极致,因为它的数学核心只有一个不等式,w+r>n。client在读取数据时,会首先确定之前写的时候写入了w个node,在读取的时候,就会读取r个node,只要保证w+r>n那么必然会有一个读取的数据是最新的数据。

从理论上来看,w+r>n,整个系统至少可以容忍n/2的node挂掉。显然我们获得了极高的可用性,但是一致性的我们就要失去了,我们需要时间去保证有w或r个node回复信息。写冲突和读冲突的问题也需要解决。

本文分享自微信公众号 - 鸿的学习笔记(shujuxuexizhilu),作者:鸿

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-02-07

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 分布式系统下的数据复制

    这是关于分布式系统下的数据的思考,对于这个思维导图,重点在于单leader的分布式复制方式,因为这个是最好实现的,而且不会遇上并发写的困境,其他的不仅会遇上时...

    哒呵呵
  • DBDB: 一个简单的key/value数据库(一)

    导论 DBDB(Dog Bed Database)是基于Python实现的key/value数据库。 它将key值与value值关联,并将该关联存储在磁盘上方便...

    哒呵呵
  • 简单定义Python和Scala的类和对象

    在现代编程语言里,类和对象都是绕不过的话题。对象这个概念可以是生活的抽象,为了更好的理解使用书来做比喻,每一本书都是一个对象,也就是一个实例,书本身具有的页码等...

    哒呵呵
  • 【工作经验分享】:在滴滴和头条干了 2 年开发,这些太真实…

    先简单交代一下背景吧,某不知名985的本硕,17年毕业加入滴滴,今年下半年跳槽到了头条,一直从事后端研发相关的工作。

    Android技术干货分享
  • 回答老板“明白了”,可真的明白了吗?

    昨天被一个下属气着了,和他交代了一个很重要的事情,反复确认“清楚了吗?”,反复回答“清楚了”,可结果仍不是自己想要的。

    架构师之路
  • 高情商技术管理者必备的5项特质

    高情商,能够帮助技术leader事半功倍的管理好团队。高情商技术管理者,要有什么特质呢?

    架构师之路
  • 请品鉴我的vim配置

    背景 本人是生信工程师,主要使用的语言是 python, R, perl, shell,经常要ssh到远程服务器上写代码,因此学习了vim,后来发现了spf13...

    生信技能树
  • 分布式系统之Raft共识算法

    分布式系统除了提升整个体统的性能外还有一个重要特征就是提高系统的可靠性。提供可靠性可以理解为系统中一台或多台的机器故障不会使系统不可用或者丢失数据。保证系统可靠...

    公众号_松花皮蛋的黑板报
  • 面试官:说一下Zookeeper的ZAB协议?敖丙:不好意思我肚子疼!

    Zab(Zookeeper Atomic Broadcast)是为ZooKeeper协设计的崩溃恢复原子广播协议,它保证zookeeper集群数据的一致性和命令...

    敖丙
  • 写给即将离开校园成为一名程序员的几句忠告

    写给即将离开校园成为一名程序员的几句忠告 转眼间又到了一年一度的毕业季,如今回首自己真正意义上的大学生活已过去整整两个春秋.谨以此文献给那些即将毕业的和还未毕...

    用户1289394

扫码关注云+社区

领取腾讯云代金券