ZooKeeper 就是上述多进程协作基础服务的一种。
ZooKeeper 的特点ZooKeeper 有几个简单特点：
- ZooKeeper 的 API：从 文件系统 API 得到的启发，提供简单的 API
- ZooKeeper 运行在专用服务器上，跟业务逻辑分离，保证了 高容错性 和 可扩展性
ZooKeeper 是存储设施，但特别注意
- ZK上存储的数据聚焦为： 协作数据 （ 元数据 ），而不是应用数据，应用数据有自己的存储方案，例如 HDFS 等
- ZK 本质上，可以看作一种 特殊的 FS
特别说明：
应用数据和元数据，由于使用场景不同，对一致性和持久性的要求有差异， 因此，架构设计、数据治理过程中，应将 2 类数据独立看待、独立存储。
ZooKeeper 的使命ZK 要解决的核心问题：
ZK 目标：简化分布式应用开发中，多进程协作问题。为分布式应用，提供 高效 、 可靠 的分布式协调服务（基础服务），例如：
- 统一的命名服务
- 分布式锁
- 进程崩溃检测
- Leader 选举
- 配置管理：配置变更时，及时下发到各个 Client。
一个简单的问题：多进程的协作是什么？尼玛呀，有完没完，啥问题你都有，面对这个掉咋天的脑壳，还是回答一下。
多进程协作，整体分为 2 类：
- 协作 ：多进程需要一同处理某些事情，一些进程采取行动是的其他进程能够正常工作，例如：主从结构，M 向 S 分配任务，S 才会执行，否则 S 就保持空闲状态
- 竞争 ：两个进程不能同时工作，一个进程必须等待另个进程执行完毕，例如：主从结构，M 节点失效后，很多 S 都想成为 M，这时，就需要互斥锁，只有第一个获得锁的 S 成为 M
特别说明：
- 不跨网络协作：多进程，可以在同一台物理主机上，同步原语很方便(比如？管道、共享内存、消息队列、信号量)
- 跨网络协作：多进程，分布在不同的物理主机上，ZK 关注这一类
跨网络多进程协作 ，进程通信，基本思路有 2 个：
共享存储
真实系统中，跨网络通信，有几个共性问题：
- 消息延迟：由于网络原因，后发送先到达
- 处理器性能：由于系统调度原因，消息到达后，延迟处理
- 时钟偏移：不同物理主机，时钟发生偏移
ZK 精心设计用于 屏蔽上述 3 个共性问题 ，使得这些问题在应用服务层面完全透明化。
ZooKeeper 特性ZooKeeper 解决的本质问题
分布式系统的一致性问题：
- 消息传递：延迟性，先发送的消息，不一定先到达；
- 消息传递：丢失性，发送的消息，可能丢失；
- 节点崩溃：分布式系统内，任何一个节点都可能崩溃；
在这种情况下，如何保证数据的一致性？
优先级最高的节点
Paxos 目标：解决 分布式一致性 问题，提高分布式系统 容错性 的一致性算法。
Paxos 本质：基于 消息传递 的 高度容错 的 一致性算法
ZooKeeper 定位
ZooKeeper 是：
- 分布式协调服务
- 高效、可靠
- 方便应用程序，聚焦 业务逻辑开发 ，而不需要过多关注 分布式进程间协作细节
ZooKeeper 不直接暴露 原语 ，而是，暴露一部分 调用方法 组成的 API，类似文件系统的 API，支持应用程序实现自己的 原语 。
ZooKeeper 特性
ZooKeeper 可以保证如下分布式一致性特性：
- 顺序一致性：同一个 Client 发起的事务请求，严格按照发起顺序执行
- 原子性：事务请求，要么应用到所有节点，要么一个节点都没有应用
- 单一视图：Client 无论连接到哪个节点，看到的服务端数据都是一致的（Note：不准确，其实是 最终一致性 ）
- 可靠性：事务一旦执行成功，状态永久保留
- 实时性：事务一旦执行成功，Client 并不能立即看到最新数据，但 ZooKeeper 保证 最终一致性
ZooKeeper 设计目标
ZooKeeper 致力于提供 高性能 、 高可用 、 顺序一致性 的分布式协调服务，保证数据 最终一致性 。
目标一：高性能（简单的数据模型）
树形结构
目标二：高可用（构建集群）
- 半数以上机器存活，服务就能正常运行
- 自动进行 Leader 选举
其他的内容都可以按照路线图里面整理出来的知识点逐一去熟悉，学习，消化，不建议你去看书学习，最好是多看一些视频，把不懂地方反复看，学习了一节视频内容第二天一定要去复习，并总结成思维导图，形成树状知识网络结构，方便日后复习。
这里还有一份很不错的《Java基础核心总结笔记》，特意跟大家分享出来， 需要的话点击这里免费获取
目录：
部分内容截图：
-UI8OZjDZ-1630157040094)]
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）