个人是非常不喜欢这个组件的,因为它的代码虐过我。引入一个Netty就可以轻易实现的网络功能,非要自己在代码里抠 NIO,代码让人看的云里雾里。
另外,Zookeeper的扩容和缩容,也曾经让我的团队吃过亏,丢了不少数据。用不好的东西,对它印象就不好,所幸它老了,我也很少用它了。
关于它的客户端使用问题,看xjjdog这篇文章就可以了。
《ZK客户端Curator使用详解》
1. 什么是 ZooKeeper
ZooKeeper是一个分布式的协调系统,应用非常广泛。它原是 Hadoop 的一个子项目,目前是 Apache 基金会的顶级项目。像我们常用的微服务框架 SpringCloud、Dubbo 等,就可以采用 Zookeeper 作为它的注册中心。
除了作为注册中心,它还有非常多的使用场景,包括:命名服务、分布式协调/通知、选举、分布式锁、分布式队列、负载均衡、配置服务等。
既然 ZooKeeper 谈到自己是一个分布式系统,那它就离不开 CAP 理论,
2. 什么是CAP理论
CAP理论,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可兼得。下面介绍一下这三个概念:
分布式系统,因为P是必须的,大多会在C和A之间做出选择。而 ZooKeeper ,就是一个倾向于 CP 的,强一致性的分布式系统。
所以我们要记住这一点,ZooKeeper 的一致性特别强,对于数据一致性要求较高的场景,ZooKeeper都可以有它的用武之地。
同时,我们也应该认识到。ZooKeeper 不能保证每次服务请求的可用性,在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果。
从官方的架构图就可以看到,不同的客户端,连接到 ZooKeeper 集群中的不同机器,所看到的数据,都是一致的,这也是它强一致性的由来。
3. ZooKeeper的使用场景
3.1 注册、配置中心
像 Spring Cloud、Dubbo 等服务节点的信息,比如机器列表等,一般数据集都比较小,但是一致性却要求非常的高,而且数据经常会发生变动,这是非常适合 ZooKeeper 的一种场景。
通过将这样的信息发布到 ZooKeeper上,那么这些数据一旦有变动,应用节点可以获得获取数据的一致视图。
3.2 分布式协调/通知
ZooKeeper有Watcher注册与异步通知机制,可以在不同的服务节点,甚至是不同的系统间进行协调。这非常像传统消息队列中的 Pub/Sub 机制,但由于 ZooKeeper的实时性,加上数据强一致性,使得数据的分发变的非常可靠。
3.3 选举
所谓的选举,就是在众多的服务节点中,选举出一个具有最终决定权的领导,这在服务集群中,一般称为Master。比如,一项服务需要对外暴露接口,但是要保证这个服务的高可用。当正在服务的节点当机之后,需要采用选举功能,从备份的机制中,选择出一台来,继续进行服务。剩余的机器,则称为这台被选举机器的备份。
3.4 分布式锁
分布式锁,是为了协调分布式环境下的共享资源而设定的锁。比如,你有一个定时服务有两个节点,但要求在执行时只有一个节点进行业务逻辑的计算。这时候,任务就变成了共享资源,在获取任务的时候,就可以采用互斥的手段来保证彼此之间的干扰,保证一致性。
3.5 分布式队列
ZooKeeper 也可以实现分布式队列,比如对一批任务的执行,先处理完前面的任务,再处理后面的任务。这个时候,就可以将任务信息存放到 ZooKeeper中。
它与消息队列的队列概念相似,但比较适合小批量的、有严格顺序的任务。
4. 相似组件
ZooKeeper 是基于 ZAB 协议构建的,这个协议和 Paxos 协议有些相似。由于这些协议太复杂了,后续又有了基于 Raft 协议的 Etcd 和 Consul。ZooKeeper 是基于Java语言开发的,而后两者是使用 Golang 开发的。
Etcd 和 Consul 作为后起之秀,在功能和性能方面要优于 ZooKeeper,它们都是 CP 的系统,使用上区别不大。
在 Java 生态里,使用 ZooKeeper 更多一些。考虑到周边建设和产品生态问题,在Java 企业级应用中, ZooKeeper 的作用还非常大。
End哪一天我再用它,那绝对只是工作需要,而不是兴趣使然。这也证明了我对它根本就不精通,虽然也买书看了一点点,但千万不要留言问我相关技术问题。
本文转载自微信公众号「小姐姐味道」,作者小姐姐养的狗。
链接:https://mp.weixin.qq.com/s/BWwRl8tBQnS3eETtB7ihRg