Zookeeper常用的应用场景

分布式协调：简单来说就是有人对Zookeeper中的数据做了监听，如果修改了Zookeeper中被监听的数据，Zookeeper反过来就会告诉发起监听的人数据变更。比如在kafka的设计中，kafka的一个节点在Zookeeper中创建了一个数据，kafka的策略是谁创建了这个数据谁就是kafka集群的主节点，其余的节点都会去监听这个数据。如果主节点宕机了，这Zookeeper对应的数据就会发送变更，即而监听这个数据的其余节点就会感知到主节点宕机，然后重新进行选举。
元数据管理：很多分布式的程序需要集中式管理自己的元数据，这个时候Zookeeper就是一个很好的选择。比如kafka、Storm等分布式的工具就会把集群里核心的元数据存放在Zookeeper中。
高可用：很多分布式项目都是主从架构（一个主节点+多个从节点）。如果只有一个主节点的话，程序就会有单点故障问题，那么这个时候就需要部署多个从节点实现高可用。如HDFS就是靠Zookeeper实现高可用的
分布式锁：注意的是Zookeeper不支持高并发，在高并发的情况建议使用Redis实现分布式锁，并发不太高的情况下使用Zookeeper实现分布式锁比较方便。

Zookeeper架构

在Zookeeper集群中，集群的服务角色分为leader和learner，learner又分为observer和follower

leader（领导者）：为客户端提供读和写的功能，负责投票的发起和决议，集群中只有leader才能接受写的服务。
follower（跟随者）：为客户端提供读服务，如果是写服务则发送给leader。在选举中进行投票。
observer（观察者）：为客户端提供读服务，如果是写服务就发送给leader。不参与leader的选举，也不参与写的过半机制。在不影响写的前提下，提高集群读写的性能，是Zookeeper3.3新增的角色
Client（客户端）：连接Zookeeper集群的使用者，请求的发起者，独立于Zookeeper集群的角色

一致性：Client客户端无论连接哪个节点，读到的数据都是一样的
实时性：Zookeeper保证客户端在一定时间间隔内获得结果，包括成功和失败，但是由于网络延迟原因，Zookeeper不能保证两台客户端同时得到更新的消息。如果都需要最新消息需要调用 sync() 接口。
原子性：leader在同步数据时，同步过程保证事务性，要么成功要么失败
顺序性：一台服务器上如果a在消息b前发布，那么所有的server上的消息a都是在消息b前发布的

来源：oschina

链接：https://my.oschina.net/u/4427158/blog/3218039

标签