指标
ZooKeeper 很风行，有个根本的疑难：
- ZooKeeper 是用来做什么的？
- 之前没有 ZK，为什么会诞生 ZK？
OK，解答一下下面的疑难：（上面是凭直觉说的）
- ZooKeeper 是用于简化分布式应用开发的，对开发者屏蔽一些分布式应用开发过程中的底层细节
- ZooKeeper 对外裸露简略的 API，用于反对分布式应用开发
- ZooKeeper 在提供上述性能的同时，其还是一个 高性能、高可用、高牢靠的分布式集群
下面说这么多，总结一下，ZK 能解决分布式应用开发的问题，ZK 能很好的解决问题。到这一步，疑难就更多了：
- 分布式应用开发，有哪些常见问题？ZK 是如何屏蔽这些底层细节的？
- ZooKeeper 对外裸露了那些 API？这些 API 如何反对分布式应用开发的？这些 API 还 - 能简化吗？API 的语义性怎么样？
- ZooKeeper 本身是一个高性能、高可用、高牢靠的分布式集群，那有个简略的问题：
- 高性能是指什么？ZooKeeper 为了达到高性能，做了哪些工作？
- 高可用同上
- 高牢靠同上
为什么有 ZooKeeper
一个应用程序，波及多个过程合作时，业务逻辑代码中混淆有大量简单的过程合作逻辑。 上述多过程合作逻辑，有 2 个特点：
- 解决简单
- 解决逻辑可重用
因而，思考将多过程合作的共性问题拎出，作为基础设施，让 RD 更加专一业务逻辑开发，即：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 采纳这种形式
实在零碎中，跨网络通信，有几个共性问题：
- 音讯提早：因为网络起因，后发送先达到
- 处理器性能：因为系统调度起因，音讯达到后，提早解决
- 时钟偏移：不同物理主机，时钟产生偏移
ZK 精心设计用于屏蔽上述 3 个共性问题，使得这些问题在应用服务层面齐全透明化。
ZooKeeper 个性
ZooKeeper 解决的实质问题
分布式系统的一致性问题：
- 消息传递：提早性，先发送的音讯，不肯定先达到；
- 消息传递：失落性，发送的音讯，可能失落；
- 节点解体：分布式系统内，任何一个节点都可能解体；
在这种状况下，如何保证数据的一致性？
- 提案投票：基于投票策略，2PC
- 选举投票：基于投票策略，投出优先级最高的节点（蕴含最新数据的节点）
Paxos 指标：解决分布式一致性问题，进步分布式系统容错性的一致性算法。
Paxos 实质：基于消息传递的高度容错的一致性算法
ZooKeeper 定位
ZooKeeper 是：
- 分布式协调服务
- 高效、牢靠
- 不便应用程序，聚焦业务逻辑开发，而不须要过多关注分布式过程间合作细节
ZooKeeper 不间接裸露原语，而是，裸露一部分调用办法组成的 API，相似文件系统的 API，反对应用程序实现本人的原语。
ZooKeeper 个性
ZooKeeper 能够保障如下分布式一致性个性：
- 程序一致性：同一个 Client 发动的事务申请，严格依照发动程序执行
- 原子性：事务申请，要么利用到所有节点，要么一个节点都没有利用
- 繁多视图：Client 无论连贯到哪个节点，看到的服务端数据都是统一的（Note：不精确，其实是最终一致性）
- 可靠性：事务一旦执行胜利，状态永恒保留
- 实时性：事务一旦执行胜利，Client 并不能立刻看到最新数据，但 ZooKeeper 保障最终一致性
ZooKeeper 设计指标
ZooKeeper 致力于提供高性能、高可用、程序一致性的分布式协调服务，保证数据最终一致性。
指标一：高性能（简略的数据模型）
- 采纳树形构造组织数据节点；
- 全量数据节点，都存储在内存中；
- Follower 和 Observer 间接解决非事务申请；
指标二：高可用（构建集群）
- 半数以上机器存活，服务就能失常运行
- 主动进行 Leader 选举
指标三：程序一致性（事务操作的程序）
- 每个事务申请，都会转发给 Leader 解决
- 每个事务，会调配全局惟一的递增 id（zxid，64 位：epoch + 自增 id）
指标四：最终一致性
- 通过提议投票形式，保障事务提交的可靠性
- 提议投票形式，只能保障 Client 收到事务提交胜利后，半数以上节点可能看到最新数据
ZooKeeper 呈现之前
ZK 呈现之前，分布式系统罕用两种形式，实现多过程合作：
- 分布式锁管理器
- 分布式数据库
ZK 更专一于过程合作，而不提供任何锁接口和通用的存储数据接口。（疑难：ZK 也能够提供啊，咱们不应用就行了）
应用服务器，常见的 2 种需要：
- Master-Slave Leader 选举：要求提供 Master 节点选举性能
- 过程响应跟踪解体检测：要求提供过程存活状态的跟踪
- 分布式锁：互斥排它锁
ZK 为上述 2 种策略提供了根底 API。
ZooKeeper 不实用的场景：
海量数据存储：ZK 实质是非凡的 FS，但 ZK 用于存储元数据，须要独自存储利用数据
专业术语介绍
文章起源：http://ningg.top/zookeeper-po…