31

重温一下ZooKeeper关键点,虽然我不是很喜欢它

 3 years ago
source link: http://mp.weixin.qq.com/s?__biz=MzA4MTc4NTUxNQ%3D%3D&%3Bmid=2650521583&%3Bidx=1&%3Bsn=5bf3d805c731b1e59082827043e18472
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

e6JBVrU.gif

不羡鸳鸯不羡仙,一行代码调半天。原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

我个人是非常不喜欢这个组件的,因为它的代码虐过我。引入一个Netty就可以轻易实现的网络功能,非要自己在代码里抠 NIO ,代码让人看的云里雾里。

另外,Zookeeper的扩容和缩容,也曾经让我的团队吃过亏,丢了不少数据。用不好的东西,对它印象就不好,所幸它老了,我也很少用它了。

关于它的客户端使用问题,看xjjdog这篇文章就可以了。

《ZK客户端Curator使用详解》

1. 什么是 ZooKeeper

YZ3UFfF.png!web

ZooKeeper是一个分布式的协调系统,应用非常广泛。它原是 Hadoop 的一个子项目,目前是 Apache 基金会的顶级项目。像我们常用的微服务框架 SpringCloud、Dubbo 等,就可以采用 Zookeeper 作为它的注册中心。

除了作为注册中心,它还有非常多的使用场景,包括:命名服务、分布式协调/通知、选举、分布式锁、分布式队列、负载均衡、配置服务等。

既然 ZooKeeper 谈到自己是一个分布式系统,那它就离不开 CAP 理论,

2. 什么是CAP理论

CAP理论,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可兼得。下面介绍一下这三个概念:

zIVnaiM.png!web

  • 一致性(C):在分布式系统的不同节点或者备份中,同一时刻是否是一样的值。比如 MySQL 的主从节点,由于 binlog 复制存在时差,可能在从机上读到的数据和在主机上的不一致。

  • 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。

  • 分区容忍性(P):集群的分区数量多了,必然会在一致性和可用性上有一些问题。以实际效果而言,分区相当于对通信的时限要求。系统如果不能在一定时间内达成数据一致性,就意味着发生了分区的情况。

分布式系统,因为P是必须的,大多会在C和A之间做出选择。而 ZooKeeper ,就是一个倾向于 CP 的,强一致性的分布式系统。

所以我们要记住这一点,ZooKeeper 的一致性特别强,对于数据一致性要求较高的场景,ZooKeeper都可以有它的用武之地。

同时,我们也应该认识到。ZooKeeper 不能保证每次服务请求的可用性 ,在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果。

iQBvyaf.png!web

从官方的架构图就可以看到,不同的客户端,连接到 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

哪一天我再用它,那绝对只是工作需要,而不是兴趣使然。这也证明了我对它根本就不精通,虽然也买书看了一点点,但千万不要留言问我相关技术问题。

作者简介: 小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,进一步交流。

后台回复“ 加群 ”,带你进入高手如云交流群

推荐阅读:


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK