Pinterest 的 ZooKeeper 经验

Pinterest 在官方博客上发布了自己对于 ZooKeeper 的运用经验，下面一起看下 Pinterest 是如何应用 ZooKeeper 及遇到的问题和解决方式

应用场景

1服务发现

Pinterest 由一些列 server 组成，这些 server 会调用后端的各种 service，而每个 service 为了负载和容错，会由多个独立的服务器组成，server 需要实时掌握可用的 service 服务器列表 每个 service 服务器都会到 ZooKeeper 下注册一个临时节点，调用者通过这些节点就可以知道可用的 service 服务器列表

当某个 service 服务器出现故障时，ZooKeeper 中的对应节点就会被删除，service 的调用者也会得到通知，同样的，有新的 service 服务器注册到 ZooKeeper 后，调用者也会得到通知 这样，调用者总是可以快速得到可用的 service 列表

2动态配置

Pinterest 的数据库是分布式结构，根据用户ID进行分库 数据库层的前端是 Data Service 数据服务层，Data Service 由很多机器组成 当一个用户请求进来时，Data Service 需要知道这个用户信息是在哪个具体的数据库中 用户ID与数据库的对于关系就是相当于一个配置信息，这个配置会变，例如增加一个新用户后，这个用户后落在某个数据库，就涉及到配置信息的变更 为了让 Data Service 的所有机器都可以快速知道最新的配置，Pinterest 把配置放在了 Zookeeper 中，Data Service 对其进行监听，配置数据有变化后，Data Service 可以立即进行更新

ZooKeeper 出现问题的因素

Pinterest 在使用 ZooKeeper 的过程中也遇到了一些问题，引发问题的因素主要包括：

1连接数太多

Pinterest 服务规模较大，与 ZooKeeper 的连接数过多，这会导致 ZooKeeper 变慢，甚至不可用

2太多的事务数

例如大规模服务器同时重启时，会产生大量的向 ZooKeeper 进行注册的事件，这个突发的峰值便会拖慢 ZooKeeper

3网络分区

极少数的情况下，会出现网络问题，导致 ZooKeeper 集群被分割在了不同的网络区域，使 ZooKeeper 出现问题

4人为错误

Pinterest 出现过因为误操作使 ZooKeeper 无法工作

尝试解决的方法

1增加容量

添加服务器，但效果不是太好，经过实践，发现服务器数量超过 10 台后，写性能会变差

2提高观察者数量

ZooKeeper 中，服务器的角色有 leader、follower，leader 由 followers 选举产生，选举机制有性能开销，follower 越多，开销越大，ZooKeeper 为了提升性能，加入了另一个角色：观察者 observer，与 follower 的区别只是没有选举功能 Pinterest 通过增加观察者角色的数量来降低 ZooKeeper 集群的负载，例如有 ZooKeeper 由10台服务器组成，如果全都参加选举的话，有性能开销，并且也没有很大的必要，就可以把5台服务器的角色变为观察者，不参与选举 但效果还是有限，在监听和读方面有作用，在写方面没什么帮助

3使用多个 ZooKeeper 集群

Pinterest 尝试使用多个 ZooKeeper 集群，不同集群负责不同的功能，例如部署系统使用一个集群，HBase 使用一个独立的集群 有效，但还不是彻底的解决方案

4回退到静态文件

Pinterest 中 ZooKeeper 的主要应用场景是服务发现和配置管理，为了防止 ZooKeeper 出现故障后产生严重影响，使用静态文件做为回退方案 使用静态文件记录服务列表和配置信息，可行，但由于数量太大，会产生管理噩梦

目前的最佳方案

左面描述的是之前使用 ZooKeeper 的方式，右面描述的是现在的替代方法 之前是各个应用直接连接 ZooKeeper，一台服务器中可能会运行多个应用，每个应用都独立维护和 ZooKeeper 的连接，ZooKeeper 出现问题后，会直接影响所有应用 替代方案是应用与 ZooKeeper 分离 每台服务器运行一个守护进程，负责与 ZooKeeper 连接，每当 ZooKeeper 中的数据有变化，例如服务列表和配置信息变更，守护进程便会得到通知，并更新到本地指定文件中，而此服务器上的所有应用只消费此文件，不再与 ZooKeeper 直接沟通 好处 （1）大大减少了 ZooKeeper 连接的数量，以前是每个应用都和 ZooKeeper 直接连接，现在是一个服务器与 ZooKeeper 建立一个连接 （2）把 ZooKeeper 出现问题时产生的影响降到最低，ZooKeeper 有问题时，受影响的是各服务器上的守护进程，由于各个应用是消费本地文件，可能会因为 ZooKeeper 出错使本地文件不是最新状态，而影响到各个应用，但影响较小，并且在紧急情况下，所有服务器上的文件内容可以被手工推送 假设 ZooKeeper 出现了数据中断，部分或者全部数据丢失，但与各服务器的守护进程的连接并没中断，这样是不是就会触发守护进程更新数据，从而使本地文件中的数据都被删除？ 这也是通过守护进程解耦 ZooKeeper 和应用的一个好处，可以在守护进程中加入自定义规则：对比接收到的新数据与文件中的数据，如果有重大嫌疑，就拒绝把新数据写入文件 就像这类大量数据丢失的情况，很容易判断出是有问题的，便不会写入本地文件，从而增强了容错能力 Pinterest 对 ZooKeeper 解耦的思路很不错，值得借鉴 原文地址：

https://engineering.pinterest.com/blog/zookeeper-resilience-pinterest