前言：
前段时间做了sdk直播服务，由于给游戏接入，所以必须要考虑并发性能问题，大家知道直播聊天，房间人数多了的话是很考验服务器的压力，服务器必须要承受较大的压力，所以考虑服务拆分 拆成分布式的，不光服务是分布式的，房间也要做到分布式的，同一个房间的人分布在不同不同的服务器上，服务器之间可以进行通信 ，分发消息。彼此之间要知道哪些服务是好的。要监控这些系统是否可用 已经房间人数负载均衡，我们就想用到了ZK 来实现我们的业务服务 比如房间人数负载均衡 服务心跳检测，zk是一个很成熟的开源产品，已经应用到了实际的产品中。所以性能稳定都是经过验证的。废话不多说，直接奔入主题吧。
简单的来介绍一下zookeeper，让我们初步认识zk是干什么的 借用官方的话来说
Zookeeper是一个高性能，分布式的，开源分布式应用协调服务。它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
zookeeper存储结构：以树形结构的方式存储数据
ZooKeeper数据模型的结构整体上可以看作是一棵树，每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识
ZK节点ZNode分为四种：
1 持久化目录节点：PERSISTENT 与客户端断开连接后 此节点还一直存在
2 持久化顺序编号目录节点：PERSISTENT_SEQUENTIAL 客户端断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
3 临时目录节点 客户端与zookeeper断开连接后，该节点被删除
4 临时顺序编号目录节点 EPHEMERAL_SEQUENTIAL 客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
Zookeeper 能给我们做什么?
1.命名服务 2.配置管理 3.集群管理 4.分布式锁 5.队列管理 6 事件监听
.Zookeeper的配置管理
Client 想zk服务端注册后 建立节点 客户端可以监听节点的任何变化，监听父节点 子节点 父子节点三种不同的三种方式。后续章节我会给大家讲解
zk服务角色描述：
Zookeeper设计目的
1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
2.可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。
3.实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4.等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
5.原子性：更新只能成功或者失败，没有中间状态。
6.顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
今天就给大家简单的介绍了zk可以干什么，后续我会继续介绍ZK的其他的一些东西，我会以项目的方式给大家介绍 一个已经运行很稳定的线上项目。
我是小志码字，一个简单码代码的小人物。
