为啥这么多公司用 ZooKeeper？它到底解决了什么问题？

目标

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...