Zookeeper|数据同步最佳实践

基本概念

项目目前采用的是分布式系统的架构，虽然不能算得上是微服务，但是也是需要部署指定服务的集群，核心业务服务部署集群和控制台服务需要通过某种方式来进行协调保证数据的一致性

目前采用的方式是通过 ZK 来进行数据的同步

涉及到一些基本概念：

• Znode（ZooKeeper Node）: ZooKeeper 的数据单位，类似于文件系统中的目录和文件。Znode 可以存储数据，客户端（也就是我们注册到 ZK 的服务，对于 ZK 来说是客户端）可以对 ZNode 进行 CRUD 操作。 ZooKeeper 使用类似于树状结构的数据模型，根节点为 /，其下可以有多个子节点，每个子节点可以继续拥有自己的子节点
• 会话（Session）: 客户端与 ZooKeeper 服务器之间的连接，每个会话有一个超时时间，若超时则会话失效。
• Watch 机制: ZooKeeper 提供的一种事件通知机制，客户端可以对特定的 Znode 设置 Watch 监听，当 Znode 发生变化时（这个变化一般来说也是业务系统中指定的操作来对 ZNode 的数据进行变化操作），ZooKeeper 会通知监听了这个 ZNode 的客户端，执行对应的操作

数据同步流程

我们这里以 核心服务集群同步来自管理控制台不断更新的商品信息 这一需求为例

也就是用户可以在管理端控制台操作更新商品信息，核心处理业务的服务需要能够同步具体的商品信息

启动 & 节点注册

客户端应用（例如 SpringBoot）在启动的时候通过 ZK 提供的客户端，比较常用的库是 Curator 来连接到 ZK 服务器

每个 SpringBoot 应用在 ZK 中注册自己的服务信息，这个服务信息，也可以是一个 ZNode (TEMPORAL类型)，当 SpringBoot 应用挂掉的时候， ZK 上对应的 ZNode 会被删除，从而实现核心服务业务和管理控制台之间状态的监听

注册 Watcher 监听

管理控制台将业务需要用到的商品数据存储在 ZK 的指定 path(例如 /coreService/instance1)上的 ZNode 上

核心服务集群中每一个实例，在启动注册的时候，都监听 ZK 的对应 path 中上的 ZNode 信息，监听的类型为 Update 事件，也就是每当 ZK 上这个 ZNode 的数据更新时，就要同步更新自己持有的商品数据

那么 ZK 上这个 ZNode 的数据什么时候会更新，就是在前端用户对商品进行修改操作的时候，管理控制台除了更新入库操作外，还要去更新 ZK 上 ZNode 的数据

当 ZK 上 ZNode 数据发生变化时，ZooKeeper 会触发 Watch 事件，我们的核心业务服务应用接收到通知后，重新读取最新的 ZNode 数据并更新（这个就要看具体业务了，在这里可能是根据商品唯一不变标识来进行内存中数据的更新操作，具体根据业务可以定制处理）

需要注意的是：Watch 事件是一次性的，应用需要在处理完事件后重新设置 Watch，以持续监听后续的变化

通过上述的流程，我们的服务应用集群的每一个节点就可以通过 ZK 来保证数据的一致性