Zookeeper和 Google Chubby对比分析
详见:http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt375
随着云计算的推广,云平台的设计和实现越来越复杂,很多系统属性如一致性和可靠性往往是在系统迭代开发时才被考虑到。如果在原生的系统上重复的实现复杂的一致性算法,这样不仅会破坏原有设计的结构,而且还带来很多开发上的负担。因此很多系统开发人员和架构师努力地进行系统划分,将系统分割成很多组件,分层设计,模块调用,从而最大限度地提高软件复用能力,降低系统设计和开发的难度。
Google在系统的可靠性方面提出了中心化的组件Chubby—粗粒度锁服务,通过锁原语为其他系统实现更高级的服务,比如组成员、域名服务和leader选举等等。Chubby本身也是一个小型的cell(通常由5个chubby结点组成),cell内部采用类似于状态机副本形式实现可靠容错。Google的Chubby论文在OSDI上发表后引起了很大的反响,原因很多,主要有两个:第一,chubby很好的解决了分布式开发的一致性问题;第二,Google Chubby采用Leslie Lamport提出的paxos算法来实现可靠容错,这是业界关于paxos第一个完整可行的实现。正因为Google Chubby,paxos这个一直沉淀在学术研究的协议,终于曝光在工业界中,之后很快地推广开去。
然而,Google Chubby并不是开源的,我们只能通过其论文和其他相关的文档中了解具体的细节。值得庆幸的是,Yahoo!借鉴Chubby的设计思想开发了Zookeeper,并将其开源。和Chubby相比,Zookeeper做了很多突破。不像Chubby的单点服务的结构,zookeeper采用多个server同时处理客户端的请求,异步读同步写,通过primary节点来同步数据的update,这一点大大改善了读服务的性能,当然弱化了客户端与服务器之间的一致性。另外,zookeeper采用block free的服务接口,采用watch机制的方式异步处理请求结果和指定数据的变更。Zookeeper对外提供了更加低级的原语primitive,基于此可以实现更多更加复杂的分布式算法,如queue、barrier和lock等等。如今很多云计算系统或者平台都使用Zookeeper来做可靠容错,进行订阅分发服务,或者其他应用。
和Chubby一样,zookeeper采用paxos的变种来实现消息传输的一致性。Zookeeper开发了原子多播协议 Zab 来实现数据的一致性传输。Zookeeper采用的是primary-backup的结构,primary节点产生non- commutative 事务,通过协议按序的广播到其他backup节点上。在节点无错的情况下,这是非常简单的事情,然而,面对复杂的网络环境,多变的软硬件条件,节点挂掉,重启,数据重复发送,这些异常很常见。Zookeeper如何做到即便是系统出现异常,也能够保证整个系统状态是一致?paxos的变种,Zookeeper的Zab协议很好的保证了这一点。
Zab 协议以epoch的方式执行(相当与序列号),在每个epoch最多只有一个进程多播数据。如果某个进程执行了协议的的第一阶段,那么进程将不再接受之前还没确定提交的epoch的数据。这样一来就保证了在进程在recovery阶段不会出现丢失已提交的数据的情况。在某个epoch下,所有参加这个epoch的进程必须此epoch之前所有已经提交的数据镜像。为了保证一致性,进程在完全恢复之前必须不能广播新的事务。Zab协议的这几个特点处理了primary异常、新旧primary以及backup节点异常的情况,的确保证了primary进程原子多播的order特性。
整个Zab协议的内容分成三个阶段:Discovery、Synchronization和Broadcast阶段。
Discovery阶段其实是选举leader或者发现leader。在这个阶段里,follower会给(可能是)leader的进程(这里的进程可以是多个)发送当前自己epoch的信息CEPOCH;如果(可能是)leader进程收到大多数的follower的CEPOCH消息,那么leader就会产生一个新epoch的消息NEWEPOCH,其中包含新的leader,并发送给follower;当follower f收到NEWEPOCH时,f会判断其中epoch是否比当前的大,如果是则反馈信息ACK-E,其中包含f所接受的最大事务编号和历史数据;leader会从这些ACK-E中选出最新的历史数据来初始化它当前的系统状态。这个阶段其实就是paxos的执行过程,由于两个大多数集合的交集肯定不为空,所以不可能一个epoch下会选出两个不同的leader。因此Discovery阶段最后的结果肯定只有一个新leader。在整个系统初始的时候,每个节点当前的epoch都为0,这样会给其它节点发送请求,这样有可能会导致paxos死锁,对此,每个zookeeper节点会通过配置获得唯一的id,并根据id的大则优先的原则来推选leader。
Synchronization阶段其实就会状态同步,新leader会将其最新状态通知给所有的follower;follower的到leader的状态后,会和自己的进行比较,从中提前还未提交的数据T,并反馈给leader;leader收到大多数确认反馈时,则发送提交命令commit给这些follower;follower收到commit后提交T中的所有数据。
Broadcast阶段和Synchronization阶段相似,只是这个阶段是对一个请求的提交而不是一个集合的提交。
Zab这三个阶段保证了前面提到的协议的几个特性,其正确性无非就是从integrity、total order 和 casual order三个方面去证明。从实际应用看,Discovery和synchronization阶段在系统状态出现不一致时,这两个阶段保证了系统即便出问题也能恢复到一致的状态;Broadcast阶段主要保证了事务执行的顺序性。
总而言之,paxos算法是Zookeeper的核心。Google Chubby架构师曾说,一切一致性协议都是paxos的变种。仔细分析,想gossip、viewstamp或者virtual synchronization其实是对relax paxos的某些条件。即便是Chubby或者Zookeeper其中采取的算法也是变种中的其中之一。Chubby和Zookeeper现有版本都是采取中心化的思想,在扩展性和性能之间的折中表现还不是很好。随着系统规模的变大和新环境的出现,如何对其去中心化并能保证可靠容错,这将是个很有趣的问题。
Zookeeper和 Google Chubby对比分析的更多相关文章
- 微软和Google的盈利模式对比分析
一: 微软和Google是世界上最成功科技巨头之一,但他们之间却有着不同的产品和业务,二者的盈利方式也各有不同,本文将分析和探讨的二者盈利模式的异同. 微软的盈利模式 在1975年由大学肄业的Bill ...
- HBase 与 Cassandra 架构对比分析的经验分享
架构对比 HBase和Cassandra几乎是一个年份发起,又都是在2010年成为Apache的顶级项目,不过如果我们去细品其内部机制,我们会发现其实两者是完全不同的架构风格. HBASE起源于Goo ...
- Android和Linux应用综合对比分析
原文地址:http://www.cnblogs.com/beer/p/3325242.html 免责声明: 当时写完这篇调查报告,给同事看了后,他觉得蛮喜欢,然后想把这篇文章修改一下,然后往期刊上发表 ...
- GitHub & Bitbucket & GitLab & Coding 的对比分析
目前基于 Git 做版本控制的代码托管平台有很多种,比较流行的服务有 Github.Bitbucket. GitLab. Coding,他们各自有什么特点,个人使用者和开发团队又该如何选择? 在这篇文 ...
- list 、set 、map 粗浅性能对比分析
list .set .map 粗浅性能对比分析 不知道有多少同学和我一样,工作五年了还没有仔细看过list.set的源码,一直停留在老师教导的:"LinkedList插入性能比Array ...
- 微信小程序、安卓APP、苹果APP对比分析
今天的话题主要是关于微信小程序.安卓APP.苹果APP对比分析.既然是对比分析肯定是将它们一个一个说明. 本篇不涉及技术话题,只讲解微信小程序.安卓APP.苹果APP它们各自的优缺点及其应用场景. 一 ...
- Apache 流框架 Flink,Spark Streaming,Storm对比分析(二)
本文由 网易云发布. 本文内容接上一篇Apache 流框架 Flink,Spark Streaming,Storm对比分析(一) 2.Spark Streaming架构及特性分析 2.1 基本架构 ...
- Python、R对比分析
一.Python与R功能对比分析 1.python与R相比速度要快.python可以直接处理上G的数据:R不行,R分析数据时需要先通过数据库把大数据转化为小数据(通过groupby)才能交给R做分析, ...
- 转: 三大WEB服务器对比分析(apache ,lighttpd,nginx) (2008年的旧文,仅供参考之用)
from: http://www.blogjava.net/daniel-tu/archive/2008/12/29/248883.html 三大WEB服务器对比分析(apache ,lighttp ...
随机推荐
- 关于Django的理解
Django的理解 Django的核心是中间件, 所有的请求和响应都会经过中间件 中间件是一个钩子框架, 它们可以介入请求的响应处理过程, 它用于在全局修改Django的输入和输出 Django有以下 ...
- 21. leetcode 492
492: 给定一个面积值,求它的长l和宽w.长和宽需满足:长大于等于宽,长和宽的差值尽可能小,长乘宽等于面积. 思路:先将l和w初始化为sqrt(area),然后看l*w是否等于面积,如果等于则返回l ...
- HDU5744 Keep On Movin (思维题,水题)
Problem Description Professor Zhang has kinds of characters and the quantity of the i-th character i ...
- .NET 微服务和Docker容器
.NET 微服务:适用于容器化 .NET 应用的体系结构 容器和 Docker 简介 什么是 Docker? Docker 术语 Docker 容器.映像和注册表 为 Docker 容器选择 .NET ...
- Restful接口调用方法超详细总结
由于在实际项目中碰到的restful服务,参数都以json为准.这里我获取的接口和传入的参数都是json字符串类型.发布restful服务可参照文章http://www.cnblogs.com/jav ...
- whatwg-fetch源码分析
fetch 是什么 XMLHttpRequest的最新替代技术 fetch优点 接口更简单.简洁,更加语义化 基于promise,更加好的流程化控制,可以不断then把参数传递,外加 async/aw ...
- 浅谈JavaScript和DOM中的类数组对象
JavaScript是一门弱类型语言,它的数据类型分为两大类:简单数据类型(5种:Undefined.Null.Boolean.Number.String)和复杂数据类型(1种:Object).Obj ...
- Tomcat结构、启动过程、关键组件简单分析
Tomcat 结构: Tomcat最顶层容器叫Server,代表整个服务器,Server中包含至少一个Service,用于具体提供服务,Serv ...
- BOM部分笔记整理
BOM部分整理 (章节 8.9) 概览: 一.介绍BOM 在web中,JS的核心对象就是BOM. 1.1 在浏览器中,window对象 == global 所以,你在全局环境下定义的变量,函数都会自动 ...
- POJ 3311 Hie with the Pie:TSP(旅行商)【节点可多次经过】
题目链接:http://poj.org/problem?id=3311 题意: 你在0号点(pizza店),要往1到n号节点送pizza. 每个节点可以重复经过. 给你一个(n+1)*(n+1)的邻接 ...