分类 Zookeeper 下的文章

zookeeper应用场景之分布式锁

zookeeper应用场景有关于分布式集群配置文件同步问题的描述,设想一下如果有100台机器同时对同一台机器上某个文件进行修改,如何才能保证文本不会被写乱,这就是最简单的分布式锁,本文介绍利用zk实现分布式锁。下面是写锁的实现步骤

分布式写锁

create一个PERSISTENT类型的znode,/Locks/write_lock

  1. 客户端创建SEQUENCE|EPHEMERAL类型的znode,名字是lockid开头,创建的znode是/Locks/write_lock/lockid0000000001
  2. 调用getChildren()不要设置Watcher获取/Locks/write_lock下的znode列表
  3. 判断自己步骤2创建znode是不是znode列表中最小的一个,如果是就代表获得了锁,如果不是往下走
  4. 调用exists()判断步骤2自己创建的节点编号小1的znode节点(也就是获取的znode节点列表中最小的znode),并且设置Watcher,如果exists()返回false,执行步骤3
  5. 如果exists()返回true,那么等待zk通知,从而在回掉函数里返回执行步骤3

- 阅读剩余部分 -

zookeeper应用场景之配置文件同步

zookeeper应用场景有关于分布式集群配置文件同步问题的描述,本文介绍如何把zk应用到配置文件分发的场景。

假设有三个角色

  • trigger:发布最新的配置文件数据,发送指令和数据给zk_agent,实现是下面的trigger.py
  • zk_agent:接收来自trigger.py触发的指令和数据,并且把数据更新到zk service上,从而触发zk_app来获取最新的配置数据,实现是下面的zk_agent.py
  • zk_app:部署在每台worker上的注册监听zk中配置文件所在znode的变化,从而获取最新的配置文件,应用到worker中,实现是下面的zk_app.py

- 阅读剩余部分 -

zookeeper中Watcher和Notifications

zookeeper中Watcher和Notifications

传统polling远程service服务

传统远程的service往往是这样服务的,服务提供者在远程service注册自己的服务,服务调用者不断去远程service轮询看看是否服务提供者有没有提供服务或者更新服务。所以有弊端,就是延时比较高,而且因为很多不必要的空轮询带来高的负载和网络损耗,这种模式到zk里面就应该是这样。

- 阅读剩余部分 -

zookeeper集群安装配置

之前介绍了zookeeper基本原理,这篇文章讲zk集群安装

zk service节点列表

192.168.1.1
192.168.1.2
192.168.1.3

zk安装包下载


[192.168.1.1]$ wget http://archive.apache.org/dist/hadoop/zookeeper/zookeeper-3.3.1/zookeeper-3.3.1.tar.gz
sudo tar -zxvf /home/wanghua.wh/zookeeper-3.3.1.tar.gz -C /usr/local/
[192.168.1.1]$ sudo mkdir /usr/local/zookeeper
[192.168.1.1]$ sudo mv /usr/local/zookeeper-3.3.1/ /usr/local/zookeeper
[192.168.1.1]$ cd /usr/local/zookeeper/conf
[192.168.1.1]$ cp zoo_sample.cfg zoo.cfg

- 阅读剩余部分 -

zookeeper基本原理

zookeeper介绍

前文介绍了zookeeper的应用场景,本文介绍下zookeeper工作原理。

zk service网络结构

zookeeper的工作集群可以简单分成两类,一个是Leader,唯一一个,其余的都是follower,如何确定Leader是通过内部选举确定的。

image

Leader和各个follower是互相通信的,对于zk系统的数据都是保存在内存里面的,同样也会备份一份在磁盘上。对于每个zk节点而言,可以看做每个zk节点的命名空间是一样的,也就是有同样的数据(下面的树结构)

  • 如果Leader挂了,zk集群会重新选举,在毫秒级别就会重新选举出一个Leaer
  • 集群中除非有一半以上的zk节点挂了,zk service才不可用

- 阅读剩余部分 -

zookeeper应用场景

分布式系统的运行是很复杂的,因为涉及到了网络通信还有节点失效等不可控的情况。下面介绍在最传统的master-workers模型,主要可以会遇到什么问题,传统方法是怎么解决以及怎么用zookeeper解决。

Master节点管理

集群当中最重要的是Master,所以一般都会设置一台Master的Backup。

Backup会定期向Master获取Meta信息并且检测Master的存活性,一旦Master挂了,Backup立马启动,接替Master的工作自己成为Master,分布式的情况多种多样,因为涉及到了网络通信的抖动,针对下面的情况:

  1. Backup检测Master存活性传统的就是定期发包,一旦一定时间段内没有收到响应就判定Master Down了,于是Backup就启动,如果Master其实是没有down,Backup收不到响应或者收到响应延迟的原因是因为网络阻塞的问题呢?Backup也启动了,这时候集群里就有了两个Master,很有可能部分workers汇报给Master,另一部分workers汇报给后来启动的Backup,这下子服务就全乱了。
  2. Backup是定期同步Master中的meta信息,所以总是滞后的,一旦Master挂了,Backup的信息必然是老的,很有可能会影响集群运行状态。

- 阅读剩余部分 -