Google Megastore读写的架构分析

原创 2011年12月04日 15:44:19

使用在什么地方?

google的megastore早在今年2月份公开后,马上就国人翻译了它,但我个人看了翻译似乎还是不怎么理解,还是看看E文的吧,这篇文章的原文直接用google搜索“google megastore” ,基本前面几条就有这篇文章了。我个人感觉,他这篇文章的主要使用之处,是对于多机房的使用,即在不同的地域之间使用paxos算法来达到数据的强一致,相对于国内多机房的数据同步,大多数公司使用mysql的slave方式来说,应该是有一定的借鉴意义的,而对于同一机房,使用master-slave和zookeeper的监控就完全足够了。


设计是怎么样的?

说完了它的使用之处后,再说说它的设计是怎么样的。显然,它最核心的部分应该是读写日志的部分了,使用了multi-paxos的算法,再加上一些优化(本地读,fast-write,multi-paxos的预分配快速写得方式),这样便构成了megastore的多机房的读写架构,后边详细讲这个读写这两块功能。当然,还需要包括一些节点失败恢复到最新状态和分区容忍(任何隔离一个机房,依然是保证数据是一致的或者不可用)的设计。


在设计过程中,google是怎么选leader的?提交数据最频繁的地方的replica作为一个leader,并且每个leader都有一个lease(租期),用完了lease再重新选择leader。对于写日志位置的话,megastore允许replicas接受out-of-order(无序)的建议,即写日志不需要按找顺序写,可以先写日志位置为101,再写日志位置为100。

  a.读设计


        读的过程图

   这里看到了Coordinator(协调器),就先说说这个Coordinator是干什么的,它其实做的事情很少:

        1). 告诉客户端本地的replica数据是不是最新的状态

        2). 如果replica(副本)没有accept(接受)写入到某一个entity group(有点类似json数据),那么Coordinator就移除这个key(commited 之前)

        3). catch up(更新)好后,让Coordinator写入这个key


    如果是current read(当前读)的过程是这样的,首先,查看本地的Coordinator,看看本地的replica是不是最新的,

        1). 如果是最新,则从本地的replica查找并读取已经接受的最大的日志位置号和时间戳

        2). 如果不是最新的,则发起一个大多数读的操作,从其他的replicas找到一个最大日志号位置,并选择一个replica,并通过该replica更新本地的replica到最新的状态;如                果这个值,该replica也无法确定是一致的,则从其他的replica读取该位置的值;如果对于一些日志位置没有包含一个已commited的值,则使用paxos发起一个no-op的                写,则最终会收敛于该某个值,我在想似乎所有的有缺少的值都可以使用paoxs发起一个no-op的写,最终都会收敛于某个值,只是这样可能代价太大点。然后,让                       Coordinator写入这个group的key

    通过,这样的操作后,使用这个log位置的时间戳从本地的replica读数据,读数据的结果可能会是多个replicas的汇聚起来的结果,这个似乎有点让人费解,读数据还需要到多个地方去读的!但,如果,本地的replica不行的话,(可以让它catch up it)就另外选择一个。


b. 写设计


        写的过程图

    在写之前,megastore要先知道下一个未使用的日志位置,和最后一次写得时间戳,以及是leader replica,由于要读取日志位置和时间戳,所以对于第一次的写过程还是需要像read那样,获得日志位置,时间戳,但是这个leader对于当前的客户端是怎么知道的,似乎没有说清楚,我在想应该是每个replica都知道才对,这个获得日志位置的同时,其实leader也知道了。

    一开始就以建议号为0发送给leader一个写的命令让其接受写在n的位置(跳过了prepare阶段),leader直接将值写在n+1的日志位置,

        1).  如果成功,则直接写入,并且让其他的replicas也在这个位置apply,如果在apply的时候不成功,则跳至下面 2)

         2). 如果不成功,则需要进行一个两阶段的paxos的算法,先prepare所有的replicas(当然,包括了leader本身),然后收到,如果超过一半接受,则发送一个accept,请求所有的replicas接受

    这里解释一下这个建议号为0,multi-paxos的一个优化是,如果上一次写成功了,则下一次写使用上一次写的一个预分配号n+1,不用再进行一次prepare阶段,而直接提交accept,但是这里和multi-paxos似乎有写区别,它是一开始就直接提交给leader,leader一接受,则其他的也replicas也跟着接受。

    这里在写入的时候似乎有点问题,如果在leader被写入,但是其他apply没有成功的时候怎么办?论文上,是这么说的,执行paxos算法后把值给替换了;那么这时候会不会有用户读取该数据会不一致呢?论文上说了,必须是让所有的Coorninators都更新了,数据才达到visibility(可见)点。

    

有问题,非常欢迎指正!

也可以直接与我(微博)讨论

论文阅读笔记 - Megastore : ProvidingScalable, Highly Available Storage for Interactive Services

作者:刘旭晖 Raymond 转载请注明出处 Email:colorant at 163.com BLOG:http://blog.csdn.net/colorant/ 更多论文阅读...
  • colorant
  • colorant
  • 2013年01月17日 11:27
  • 2720

Google Megastore读写的架构分析

使用在什么地方? google的megastore早在今年2月份公开后,马上就国人翻译了它,但我个人看了翻译似乎还是不怎么理解,还是看看E文的吧,这篇文章的原文直接用google搜索“google ...
  • techq
  • techq
  • 2011年12月04日 15:44
  • 6669

Altera IP MegaStore

  • 2010年08月23日 10:43
  • 13.35MB
  • 下载

Google Megastore分布式存储技术全揭秘

Google Megastore分布式存储技术全揭秘 2011-02-16 09:41 |  6380次阅读 |  【已有6条评论】发表评论 来源:CSDN |  作者: |  收藏到我的网摘 ...
  • wangdk789
  • wangdk789
  • 2013年12月17日 13:50
  • 610

Google Megastore分布式存储技术全揭秘(3)

Google Megastore分布式存储技术全揭秘(3)2011-02-16 09:41  |  22952次阅读  |  【已有22 条评论】发表评论来源:CSDN  |  作者: ...
  • xgbjmxn
  • xgbjmxn
  • 2011年02月21日 18:58
  • 366

Google Megastore分布式存储技术全揭秘

导读:本文根据Google最新Megastore论文翻译而来,原作者为Google团队,团队人员包括:Jason Baker,Chris Bond,James C.Corbett,JJ Furman,...
  • yczz
  • yczz
  • 2011年03月15日 14:35
  • 1144

大规模分布式存储系统:原理解析与架构实战.杨传辉.pdf

  • 2017年09月29日 14:39
  • 87.26MB
  • 下载

Google网站架构分析

http://www.fovweb.com/web/google-structure-analysis.html2009年5月3日Google是可伸缩性之王。每个人都知道Google是因为他们对大量,...
  • ccwwff
  • ccwwff
  • 2011年03月07日 23:02
  • 2263

Google Megastore分布式存储技术全揭秘(2)

Google Megastore分布式存储技术全揭秘(2)2011-02-16 09:41  |  22951次阅读  |  【已有22 条评论】发表评论来源:CSDN  |  作者: ...
  • xgbjmxn
  • xgbjmxn
  • 2011年02月21日 18:57
  • 402

Megastore,google关于存储的论文

  • 2011年02月18日 13:21
  • 931KB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Google Megastore读写的架构分析
举报原因:
原因补充:

(最多只允许输入30个字)