参考： B战《黑马程序员Zookeeper视频教程，快速入门zookeeper技术》 B站《为什么微服务与高并发程序都在放弃 Zookeeper》
目录
1、Zookeeper概念2、Zookeeper功能2.1、配置管理2.2、分布式锁2.1、集群管理
3、为什么微服务与高并发程序都在放弃 Zookeeper问题一：基于cp（强一致性）的设计问题二：持久化中间状态问题三：健康检测
4、ZK可应用场景
1、Zookeeper概念
Zookeeper是一个分布式的、开源的分布式应用程序的协调服务。（起辅助功能的项目）
2、Zookeeper功能
2.1、配置管理
有A、B、C三个应用程序，都有各自的配置文件，如果都连接同一个数据库，当数据库的信息发生改变时，就需要同时修改全部的配置文件，费时费力。 引入配置中心，把公有的配置放入配置中心，同时修改。应用程序启动时从配置中心下载并加载自己的配置文件。
2.2、分布式锁
部署在同一机器上，多线程访问公共部分，可以通过synchronized实现同步。但是如果部署在不同机器上怎么办？这时共享资源可能被同时访问。 引入第三方分布式锁，部署在不同机器上的程序通过分布式锁获取访问资格。
2.1、集群管理
作为注册中心进行使用。provider把自己的地址放到注册中心。consumer先从注册中心获取provider的地址，再通过RPC的远程调用。
3、为什么微服务与高并发程序都在放弃 Zookeeper
问题一：基于cp（强一致性）的设计
zk集群架构如下： 应用写入数据，由于zk（zookeeper）是基于cp（强一致性）的设计，leader向follower复制的过程中，follower没有处理完成，leader会一直阻塞，不会向应用返回响应。虽然主从复制可能只会持续十多ms的时间，但在高并发状态影响很大（基于AP的设计会更好）。
补充： 1在分布式中P是必须要有的，所以分布式有CP和AP两种模式。AP的就是可用性强，一致性弱；CP就是一致性强,可用性弱。 2可用性：任何时候，读写都是成功的，即服务一直可用，而且是正常响应时间。 3一致性：所有节点同时看到相同的数据。
问题二：持久化中间状态
为了让数据可靠，zk会把中间状态也进行持久化，增加很多操作。但对于分布式架构，想知道的是当下哪些结点是存活的，寻找存活结点发起RPC（远程调用），不关心中间过程。
问题三：健康检测
zk的健康检测绑定在基于TCP长连接的探活上了，对于应用本身是否可用并不关心（健康检测不彻底，连接好不代表应用还好着）。
4、ZK可应用场景
适用于必须基于cp的场景下： 1数据订阅发布：主从是一致的，不会出现数据中间状态问题。 2命名服务：为每一个结点分配唯一的全局编号。 3分布式锁
好文推荐
发表评论