分布式桥梁分布式桥梁ZooKeeper开发体验开发体验
从传统Java Web转入分布式系统应用,再到接触分布式协调框架ZooKeeper,通过痛苦的思维逻辑和理念转变,历经一个月
时间,小伙伴们终于把ZooKeeper嵌入到了BoCloud博云的BeyondContainer中,并在其上进行相应功能的开发:服务注册与
发现、集群管理、模块的高可用及分布式锁等。
在选定ZooKeeper之前,我们对其他的分布式框架也进行了调研和对比,分别 有etcd和consul。对于etcd而言,在原生接口和
提供服务方式方面,etcd更适合作为集群配置服务器,用来存储集群中的大量数据,方便的REST接口也可以让集群中的任意
一个节点在使用key |value服务时获取方便,然而etcd在监控服务的状态和通知方面比较麻烦;consul方面,是使用Go语言开发
的分布式协调,对业务发现的管理提供很好的支持,他的HTTP API也能很好的和不同的语言绑定,但在业务检测方面有一定
的延时,不太适合实时响应的情景;并且etcd和consul需要其他组件的配合才能达到ZooKeeper的服务能力,故ZooKeeper则更
加的适合于提供分布式协调服务,实现分布式锁模型方面也较为简单方便,并且功能全,社区活跃,用户群体很大,对所有典
型的用例都有很好的封装,支持不同语言的绑定,故最终选定ZooKeeper。
在产品开发中使用ZooKeeper是一件有趣的事情,下面就让我们来详细扒一扒我们的开发体验吧。
一、简单介绍
先来简单说明下ZooKeeper原理,再来谈谈在产品中的具体使用。ZooKeeper是一个开放源码的分布式应用程序协调服务,由
知名互联网公司雅虎创建,是Google Chubby的开源实现。设计目标是为分布式提供一致性服务,其没有直接采用Paxos算
法,而是采用了被称为ZAB的一致性协议。ZooKeeper具有以下几个特征:
1、数据模型
ZooKeeper使用一个共享的、树形结构的名字空间-数据模型,其由一系列被称为ZNode的的数据节点组成,其层级关系,如
文件系统的目录结构一样,结构如下图所示:
每个Znode上都会保存自己的数据内容以及属性信息,节点分为持久节点和临时节点,持久节点除非进行删除操作,否则将会
一直保存在ZooKeeper上;而临时节点,他的生命周期和客户端会话绑定,一旦会话失效,这个客户端所创建的所有临时节点
都会被删除。另外,可以给节点加上一个属性:sequential,节点创建的时候,会自动在节点后面追加一个由父节点维护的自
增数字。
2、构建集群
一个ZooKeeper集群通常由一组机器组成,一般3-5台机器就可以组成一个可用的集群,其结构和工作原理如下图所示:
只要集群中存在超过一半的机器能够正常工作,集群就能够正常对外服务。
ZooKeeper具有以下三种角色:
Leader: 为客户端提供读写服务
Follower:为客户端提供读服务,参与Leader选举过程
Observer:为客户端提供读服务,不参与Leader选举过程