专栏名称: 林湾村龙猫

资深后台开发

一篇文章深入浅出理解zookeeper

林湾村龙猫 · 掘金 · · 2018-11-20 03:00

正文

随着互联网技术的发展，大型网站需要的计算能力和存储能力越来越高，网站架构逐渐从集中式转变成分布式系统。

虽然分布式相对于集中式系统有比较多的优势，比如更高更强的计算、存储、处理能力等。但同时也引入了其他一些问题，比如如何在分布式系统中保证数据的一致性和可用性。

在日常中，如果两个员工或用户对某件事产生了分歧，通常我们的做法是找上级，去做数据和信息的同步。

那么对于我们的服务呢，多个节点之间数据不同步如何处理？

在单机发展到集群、分布式服务的过程中，每一件技术或工具都走向了系统化，专一化的道路。举个例子，在单体应用中，如果多个线程想对同一个变量进行修改，我们通常的做法是对要修改的变量或资源加锁。那么对于集群来说，并没有这样的东西，我们应该怎么做？

对于分布式集群来说，这个时候，我们通常需要一个能够在 各个服务或节点之间 进行协调的 服务或中间人

架构设计中，没有一个问题不能通过一层 抽象层 来解决，如果有，那就是两层。

集群管理

我们可以一起看看，协调服务中的佼佼者--ZooKeeper

zookeeper起源

zoo

最初，在Hadoop生态中，会存在很多的服务或组件（比如hive、pig等），每个服务或组件之间进行协调处理是很麻烦的一件事情，急需一种高可用高性能数据强一致性的协调框架。因此雅虎的工程师们创造了这个中间程序，但中间程序的命名却愁死了开发人员，突然想到hadoop中的大多是动物名字，似乎缺乏一个管理员，这个程序的功能有是如此的相似。因此zookeeper诞生。

zookeeper提供了哪些特性，以便于能够很好的完成协调能力的处理呢？

功能与特性

数据存储

zookeeper提供了类似Linux文件系统一样的数据结构。每一个节点对应一个Znode节点，每一个Znode节点都可以存储1MB（默认）的数据。

客户端对zk的操作就是对Znode节点的操作。

zookeeper数据结构

Znode:包含ACL权限控制、修改/访问时间、最后一次操作的事务Id(zxid)等等
说有数据存储在内存中，在内存中维护这么一颗树。
每次对Znode节点修改都是保证顺序和原子性的操作。写操作是原子性操作。

举个例子，在注册中心中，可以通过路径"/fsof/服务名1/providers"找到"服务1"的所有提供者。

每一个Znode节点又根据节点的 生命周期 与类型分为4种节点。

zookeeper节点

生命周期：当客户端会话结束的时候，是否清理掉这个会话创建的节点。持久-不清理，临时-清理。
类型：每一个会话，创建单独的节点（例子：正常节点：rudytan,顺序编号节点：rudytan001,rudytan002等等）

监听机制

zookeeper除了提供对Znode节点的处理能力，还提供了对节点的变更进行监听通知的能力。

zookeeper监听机制

监听机制的步骤如下：

任何session(session1,session2)都可以对自己感兴趣的znode监听。
当znode通过session1对节点进行了修改。
session1,session2都会收到znode的变更事件通知。

节点常见的事件通知有：

session建立成功事件
节点添加
节点删除
节点变更
子节点列表变化

需要特别说明的是：

一次监听事件，只会被触发一次，如果想要监听到znode的第二次变更，需要重新注册监听。

到这里，我们了解到zookeeper提供的能力，那我们在哪些场景可以使用它？如何使用它呢？

应用场景

zookeeper用得比较多的地方可能是，微服务的集群管理与服务注册与发现。

注册中心

注册中心模型

依赖于 临时节点
消费者启动的时候，会先去注册中心中全量拉取服务的注册列表。
当某个服务节点有变化的时候，通过 监听机制 做数据更新。
zookeeper挂了，不影响消费者的服务调用。

目前还有个比较流行的服务Eureka也可以做注册中心，他们有什么优势和劣势呢？留个疑问，哈哈哈。

分布式锁

分布式锁

依赖于 临时顺序节点
判断当前client的顺序号是否是最小的，如果是获取到锁。
没有获取到锁的节点监听最小节点的删除事件（比如lock_key_001）
锁释放，最小节点删除，剩余节点重新开始获取锁。
重复步骤二到四。

redis和db也能创建分布式锁，哪有什么异同呢？留个疑问，哈哈哈。

分布式锁可以参考我的另一篇文章：分布式锁 www.jianshu.com/p/e4174e499…

集群管理与master选举

集群管理与master选举

依赖于 临时节点
zookeeper保证 无法重复创建一个已存在的数据节点 ，创建成功的client为master。
非master，在已经创建的节点上 注册节点删除事件 监听。
当master挂掉后，其他集群节点收到节点删除事件，进行重新选举
重复步骤二到四

当然还有其他应用场景，不一一列举了。

有人说，zookeeper可以做分布式配置中心、分布式消息队列，看到这里的小伙伴们，你们觉得合适么？

到这里，可以基本上满足基于zk应用开发的理论知识储备。对原理或有更强求知欲的小伙伴可以继续往下看，接下来聊聊zookeeper如何做到高性能高可用强一致性的。