Zookeeper实践篇-Zookeeper经典场景实践，闭关在家37天“吃透”这份345页PDF

Zookeeper是一个高可用的分布式数据管理与分布式协调服务框架，并且因为自身的Zab协议实现，使得zk可以做到保证分布式场景中的一致性。因此伴随着分布式的发展，zk用来解决分布式的场景越来越多，例如配置中心、服务治理、分布式锁、分布式队列等，接下来我们来看看这些常见的分布式场景下zk的处理和实现原理。

数据发布/订阅(配置中心)

在分布式开发中，我们往往需要实现一个统一的分布式的配置中心，在我们系统较少的场景下，往往是使用的本地配置文件的方式来处理，但是当分布式环境中，每次进行配置文件的变更，都需要将所有的机器的配置修改，甚至需要重新启动服务，这点对于开发和使用来说非常不便，后来也出现了很多配置中心的方案，例如etcd，或者apollo等，而zk作为通用的分布式协调系统，自然也可以实现理想的配置中心，即使用zk的数据发布/订阅。

发布/订阅一般来说在很多系统中都有使用，大体的实现方式主要分为两种：推–拉，而所谓的推模式，则是服务端将配置的数据变更信息主动发送给所有的订阅的客户端，而拉模式则是反过来，是由所有的订阅的客户端，主动发起请求来获取服务端数据，一般都是客户端采用定时轮询的机制来实现。但是我们可以思考这两种模式自身的优缺点，例如推模式，就存在很大可能，在服务端网络不佳的场景下，推模式可能会导致大量的延迟甚至推送失败，导致客户端大量接受不到新的数据变更等问题，而拉模式也可能存在每个客户端主动拉取数据的延迟性，例如30s轮询一次服务端，但是在这个时间间隔内可能会导致大量的请求不可达或者服务不可用，也会因为每个客户端的网络和启动时间等原因导致，部分客户端已经轮询到了最新的数据，而部分客户端依然是上一次的旧数据的情况。可见，无论是哪种模式，都存在一定的弊端，也有一定的优势，而zk的发布/订阅则是基于推拉结合的模式，具体实现原理如下：

客户端向服务端注册需要订阅的节点，而订阅则会使得客户端本地存在一个回调通知机制(watch)，一旦服务端发现这个节点有数据变更，就去主动的将变更的信息推送给每一个客户端，触发客户端的watch机制。

那么，我们如果通过zk实现配置中心，该如何操作呢？大致可以分为以下三步：

1、配置的存储

在进行配置存储之前，我们需要在zk上创建一个节点，用来初始化阶段将数据存储进去，例如**/app1/database_config**节点：

然后将需要管理的配置信息写入

2、配置获取

分布式集群环境中的每台机器在工程初始化的时候，都会去zk上初始化一个配置信息，并且向该节点注册一个watch，一旦该节点的数据发生了变更，所有的客户端都会获取到数据变更的通知

3、配置变更

在分布式系统运行的过程中，可能会出现配置修改的情况，这个时候就需要将zk上该节点的配置进行更新，当我们触发完修改操作后，zk的服务端就会将此变化发送给所有的客户端，当客户端收到通知以后，则可以重新进行最新数据的获取

Master选举

Master选举是分布式系统中最常见的应用场景之一，我们常用的组件，例如kafka等就是借助zk实现的Master选举，除此之外，大数据中的组件也有很多利用zk实现选举等功能的。而Master往往是一个分布式系统中具有协调其他系统单元，具有系统中状态变更的决定权。

在前面的文章中，我们学习过zk创建节点的Api特性，其中很重要的一点就是，zk自身具有强一致性，可以保证在分布式环境下高并发创建节点一定可以保证全局唯一。即无法重复的创建一个已经存在的数据节点。如果有多个客户端同时请求创建该节点，那么最终只有一个客户端能创建成功，利用这个特性，就可以简单的实现Master选举等功能。

例如，我们在系统中创建一个日期节点，例如‘2013-09-20’，如图：

而客户端每天定时往zk的对应日期节点中创建一个临时节点，例如图中的**/master_election/2013-09-20/binding**节点，只有一个客户端可以创建这个节点，而其他客户端都是创建失败，此时创建成功的客户端自然而然可以视为master，具有一定的管理权。而创建失败的客户端则可以选择对该节点注册一个watch，用来监控master节点，一旦发现master挂了，所有的客户端收到通知后，再次去创建binding节点，重复上述操作即可保证master节点的选举操作了。

分布式锁

分布式锁是控制分布式系统之间同步访问资源的一种方式，如果在分布式系统下，需要共享访问一个或者一组资源，那么访问这些资源的时候，往往需要一些互斥的手段来保证一致性，这种场景下就需要使用分布式锁了。而zk可以实现的分布式锁一般分为共享锁和排他锁两种。

排他锁

排他锁又称写锁或者独占锁，是一种基本的锁类型。如果对客户端对数据对象O1添加了排他锁，那么在整个持有锁的过程中，只允许当前客户端对O1进行读取和更新操作。在zk中，我们可以通过节点来标识一个锁，例如**/exclusive_lock/lock**节点被定义为一个锁，如图所示：

在获取排他锁的时候，所有的客户端都会试图通过create()方法去在/exclusive_lock下面创建临时节点**/lock**，而zk的创建方法最终能保证只有一个客户端创建成功，此客户端则认为成功获取到了锁，其他客户端创建失败以后，则可以选择注册一个watch监听。我们创建的锁节点属于临时节点，因此在以下两种情况下，都有可能被释放：

1.由于临时节点的特性，不会进行持久化保存，而是和当前连接的session关联，因此当服务器出现宕机的情况下会被释放

2.在创建临时节点成功后，客户端执行需要处理的业务操作完毕后，主动调用临时节点的删除操作

因此无论什么情况下移除了/lock节点，zk都会将事件通知给所有的watch监听的客户端。而这个时候所有的客户端则可以在收到通知后，再次发起创建节点的请求操作，重复上面的操作。整个排他锁的流程如图所示：

共享锁

我们在日常开发过程中，还会使用到一个共享锁。所谓共享锁，又称之为读锁，即如果当前资源O1被挂载了共享锁，那么其他的客户端只能对当前的资源O1进行读取的操作，而不是进行更新操作，但是当前资源可以同时挂载多个共享锁，如果想要更新当前资源，则需要挂载的共享锁全部释放。与排他锁不同的是，排他锁仅仅对一个客户端可见，而共享锁则是可以对多个客户端同时可见。

我们同样可以使用zk的临时节点来实现共享锁操作，我们指定一个节点/sharedlock为共享锁的节点，而每个客户端则是在当前节点下创建临时顺序节点，例如**/shared****lock/192.168.1.1-R-000000001**，节点名称规则为/shared_lock/ip-读写类型-临时节点序号，如图：

当所有的客户端都创建完属于自己类型的共享锁后，我们则需要进行读写规则判断，确定当前各个客户端对资源的操作属于读还是写操作，大概如下几个步骤：

1.每个客户端都在当前节点下创建对应规则类型的临时顺序节点，并且对该节点注册一个子节点变更的watch监听

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V：vip1024b 备注Java获取（资料价值较高，非无偿）

写在最后

很多人感叹“学习无用”，实际上之所以产生无用论，是因为自己想要的与自己所学的匹配不上，这也就意味着自己学得远远不够。无论是学习还是工作，都应该有主动性，所以如果拥有大厂梦，那么就要自己努力去实现它。

最后祝愿各位身体健康，顺利拿到心仪的offer！

由于文章的篇幅有限，所以这次的蚂蚁金服和京东面试题答案整理在了PDF文档里

3ze-1711591060012)]

[外链图片转存中…(img-YITO3MB6-1711591060012)]

[外链图片转存中…(img-EQUenC6X-1711591060013)]