分布式助手Zookeeper（一）

水深无声 2022-04-21 14:13 216阅读 0赞

\[b\]\[color=olive\]\[size=large\]Zookeeper最早是Hadoop的一个子项目，主要为Hadoop生态系统中一些列组件提供统一的分布式协作服务，在2010年10月升级成Apache Software  
Foundation(ASF)顶级项目，它主要提供以下的四个功能：  
\[table\]  
|功能名|  
|组管理服务|  
|分布式配置服务|  
|分布式同步服务|  
|分布式命名服务|  
\[/table\]  
Zookeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户；  
Zookeeper的架构图如下：  
\[/size\]\[/color\]\[/b\]  
  
\[img\]http://dl2.iteye.com/upload/attachment/0091/8360/2f9be92b-4e1b-3d9e-b79d-40cbfe6c77ad.jpg\[/img\]  
\[b\]\[color=green\]\[size=large\]  
Zookeeper的特点如下：  
\[table\]  
|特点|说明|  
|最终一致性|为客户端展示同一个视图，这是zookeeper里面一个非常重要的功能|  
|可靠性|如果消息被到一台服务器接受，那么它将被所有的服务器接受。|  
|实时性|Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。|  
|独立性|各个Client之间互不干预|  
|原子性|更新只能成功或者失败，没有中间状态。|  
|顺序性|所有Server，同一消息发布顺序一致。  
\[/table\]  
\[/size\]\[/color\]\[/b\]  
\[b\]\[color=olive\]\[size=large\]  
zookeeper的工作原理，  
1.每个Server在内存中存储了一份数据；  
2.Zookeeper启动时，将从实例中选举一个leader（Paxos协议）  
3.Leader负责处理数据更新等操作（Zab协议）；  
4.一个更新操作成功，当且仅当大多数Server在内存中成功修改数据。  
\[/size\]\[/color\]\[/b\]  
\[b\]\[color=green\]\[size=large\]  
zookeeper中的几个重要角色：  
\[table\]  
|角色名|描述  
|领导者(Leader)|领导者负责进行投票的发起和决议，更新系统状态，处理写请求  
|跟随者(Follwer)|Follower用于接收客户端的读写请求并向客户端返回结果，在选主过程中参与投票  
|观察者（Observer）|观察者可以接收客户端的读写请求，并将写请求转发给Leader，但Observer节点不参与投票过程，只同步leader状态，Observer的目的是为了，扩展系统，提高读取速度。  
|客户端(Client)|执行读写请求的发起方  
\[/table\]  
\[/size\]\[/color\]\[/b\]  
  
\[b\]\[color=olive\]\[size=large\]为什么，在3.3.0版本之后，引入Observer角色？  
  
Zookeeper需保证高可用和强一致性；  
为了支持更多的客户端，需要增加更多Server；  
Server增多，投票阶段延迟增大，影响性能；  
权衡伸缩性和高吞吐率，引入Observer  
Observer不参与投票；  
Observers接受客户端的连接，并将写请求转发给leader节点；  
加入更多Observer节点，提高伸缩性，同时不影响吞吐率。  
  
\[/size\]\[/color\]\[/b\]  
  
\[b\]\[color=green\]\[size=large\]  
为什么zookeeper集群的数目，一般为奇数个？  
  
Leader选举算法采用了Paxos协议；  
Paxos核心思想：当多数Server写成功，则任务数据写成功  
如果有3个Server，则两个写成功即可；  
如果有4或5个Server，则三个写成功即可。  
Server数目一般为奇数（3、5、7）  
如果有3个Server，则最多允许1个Server挂掉；  
如果有4个Server，则同样最多允许1个Server挂掉  
由此，我们看出3台服务器和4台服务器的的容灾能力是一样的，所以  
为了节省服务器资源，一般我们采用奇数个数，作为服务器部署个数。  
\[/size\]\[/color\]\[/b\]  
\[b\]\[color=olive\]\[size=large\]  
zookeeper的数据模型：  
基于树形结构的命名空间，与文件系统类似  
节点（znode）都可以存数据，可以有子节点  
节点不支持重命名  
数据大小不超过1MB（可配置）  
数据读写要保证完整性  
层次化的目录结构，命名符合常规文件系统规范；  
每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识；  
节点Znode可以包含数据和子节点（EPHEMERAL类型的节点不能有子节点）；  
Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据需带上版本；  
客户端应用可以在节点上设置监视器（Watcher）；  
节点不支持部分读写，而是一次性完整读写。  
  
Znode有两种类型，短暂的（ephemeral）和持久的（persistent）；  
Znode的类型在创建时确定并且之后不能再修改；  
短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点；  
持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除；  
Znode有四种形式的目录节点，PERSISTENT、PERSISTENT\_SEQUENTIAL、EPHEMERAL、EPHEMERAL\_SEQUENTIAL。  
  
  
\[/size\]\[/color\]\[/b\]  
  
\[b\]\[color=green\]\[size=large\]Zookeeper的应用场景一（统一命名服务）  
分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务；  
类似于域名与ip之间对应关系，域名容易记住；  
通过名称来获取资源或服务的地址，提供者等信息  
按照层次结构组织服务/应用名称  
可将服务名称以及地址信息写到Zookeeper上，客户端通过Zookeeper获取可用服务列表类  
  
\[/size\]\[/color\]\[/b\]  
  
  
\[b\]\[color=green\]\[size=large\]Zookeeper的应用场景二（配置管理）  
分布式环境下，配置文件管理和同步是一个常见问题；  
一个集群中，所有节点的配置信息是一致的，比如Hadoop；  
对配置文件修改后，希望能够快速同步到各个节点上  
配置管理可交由Zookeeper实现；  
可将配置信息写入Zookeeper的一个znode上；  
各个节点监听这个znode  
一旦znode中的数据被修改，zookeeper将通知各个节点  
  
\[/size\]\[/color\]\[/b\]  
  
\[b\]\[color=green\]\[size=large\]Zookeeper的应用场景三（集群管理）  
  
分布式环境中，实时掌握每个节点的状态是必要的；  
可根据节点实时状态作出一些调整；  
可交由Zookeeper实现；  
可将节点信息写入Zookeeper的一个znode上；  
监听这个znode可获取它的实时状态变化  
典型应用  
Hbase中Master状态监控与选举  
\[/size\]\[/color\]\[/b\]  
\[b\]\[color=green\]\[size=large\]Zookeeper的应用场景四（分布式通知和协调）  
分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态；  
NameNode须知道各DataNode的状态  
JobTracker须知道各TaskTracker的状态  
心跳检测机制可通过Zookeeper实现；  
信息推送可由Zookeeper实现（发布/订阅模式）  
\[/size\]\[/color\]\[/b\]  
  
\[b\]\[color=green\]\[size=large\]Zookeeper的应用场景五（分布式锁）  
Zookeeper是强一致的；  
多个客户端同时在Zookeeper上创建相同znode，只有一个创建成功。  
实现锁的独占性  
多个客户端同时在Zookeeper上创建相同znode ，创建成功的那个客户端得到锁，其他客户端等待。  
控制锁的时序  
各个客户端在某个znode下创建临时znode （类型为CreateMode.EPHEMERAL\_SEQUENTIAL），这样，该znode可掌握全局访问时序。  
  
\[/size\]\[/color\]\[/b\]  
  
\[b\]\[color=green\]\[size=large\]Zookeeper的应用场景六（分布式队列）  
两种队列；  
当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。  
队列按照 FIFO 方式进行入队和出队操作，例如实现生产者和消费者模型。（可通过分布式锁实现）  
同步队列  
一个job由多个task组成，只有所有任务完成后，job才运行完成。  
可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时znode，一旦临时节点数目达到task总数，则job运行完成。  
  
\[/size\]\[/color\]\[/b\]