利用的配置ZooKeeper服务实现分布式系统数据同步 - 副本.docVIP

利用ZooKeeper服务实现分布式系统的配置数据同步 很多时候，一旦习惯了某些事情，也就习惯了它们的恶劣，习惯了它们的丑陋，习惯了它们“赋予”你的各种痛苦。 – Tony Bai 一、痼疾难解 我们目前的业务配置数据同步方案。简单描述这个方案如下： 方案涉及两个角色 – 数据库(DB)与应用节点（app_node)； 所有的业务配置数据均统一存储在DB中； 应用节点在启动后从DB中读取最新业务配置数据； 应用节点运行过程中，如果DB中的业务配置数据发生变更（增/删/改），DB中的触发器(trigger)将会执行。在触发器的脚本中，触发器将会【串行】地与每个应用节点建立TCP链接，并将业务配置表的变更信息发给各个应用节点。应用节点会接收并【解析】触发器发过来变更数据包，并同步到自己的本地内存中。这样就达到了运行时更新配置的目的。 曾几何时，在那个还没有集群化，没有分布式的时代，它还是一个不错的方案，至少在线上没有暴露出太多问题，它也不在我们关注的重点范围之内。但随着集群化、分布式的新版本的到来，那一大坨遗留的代码就变得格外让人不顺眼，同时问题也随之在线上暴露开来了。 上面我用【】标记了两个关键词：“串行”和“解析”。这两个词隐含有这个方案的两个主要问题。 “串行” – 意味着每一次DB的业务配置数据变更，trigger脚本都要逐个与应用节点建立链接并收发数据。当应用节点逐渐增多时，每一次业务数据同步都会相当地耗时。尤其是当某个应用节点所在主机出现问题时，到该节点链接建立的过程会阻塞，导致整个业务配置数据同步的时间达到无法忍受的地步。 “解析” – 我们自定义了trigger与应用节点之间的协议包。协议包中包含了每次变更的详细信息，比如在某个表添加一条记录，trigger会将这个记录的每个字段信息排成一行打包发给应用节点。应用节点收到这个包后，会根据已有的表字段信息对该包进行解析。看得出这是一个很强的耦合：表字段一旦修改，trigger脚本要修改，应用节点的解析函数要修改，还要考虑协议包中表字段的排序。如果应用节点解析时与trigger脚本打包时的字段顺序不同的话，那就可能出现严重错误，而且这种错误有时难于校验并难于发现。 二、曾经的努力 针对这个方案的不足，我们曾经也做过改进，但主要针对的是解决“串行”这个问题上。 第一次改进：同步的发起能否并行做？trigger脚本能否并行发起对各个应用节点的链接建立请求？ Java组同事对trigger脚本做了改进。让trigger脚本调用function，而function中又调用了写好的Java方 法，Java代码由DB加载到环境中。在Java方法中创建多个同步线程，并发与各应用节点建立链接并发送数据。这个方法的确可以变“串行”为“并行”，但不知为何生产环境中实际运行时偶尔会出现异常，该异常发生在DB中，影响很大。有时还会导致DB的一些异常现象。至今原因尚未明确， 我们无奈退回到以前的方案。 第二次改进：从Push模式到Pull模式 在之前部门新规划的一个产品中，开发人员对数据同步的机制做了重新的设计，将原来的Push模式改为了Pull模式。大致方案是： 业务数据变更时，trigger直接将变更内容（以老方案中那个协议包的打包格式）写到一个“变更日志表”中，每条记录有一个唯一的序号，序号递增。 应用节点启动后，从DB加载最新配置信息，查询“变更日志表”，得到该表内最新的一条记录的序号n。 应用节点以“轮询”的方式定期查询“变更日志表”，并读取和解析那些序号比序号n更新的记录；更新完后，将继续保存最新的一条记录序号。 数据库中有job定期对“变更日志表”中的记录进行过期删除处理。 个人感觉第二个方案应该是理想方案的一个雏形，虽然目前它的同步更新可能不是那么及时，与DB交互过多（方案细节中每个应用节点在处理完一条记录 后还要更新记录的状态）。该方案设计者也完全也可以放弃那个导致耦合的协议包设计，但他最终还是选择保留了原有协议包解析函数。目前该方案在产品环境下运行还算良好，并未暴露出什么问题。这算是一次有效的改进，也为本文中要提到的方案提供了一些思路启示。 三、与时俱进 ZooKeeper生来就具备解决分布式系统的配置分发和同步的能力。利用ZooKeeper服务实现分布式系统的统一配置中心已经不是那么新鲜的话题了。最简单的模型莫过于将配置数据存储在ZooKeeper上的路径节点上，然后应用节点在这些配置节点上添加watch。当配置数据变更时，每个应用节点都可以及时得到通知，同步到最新数据。这种模型对于一些量少简单的系统配置来说较为合适。对于我们每个表动辄上万条配置的情形似乎不那么适合，想象一下每个应用节点要添加上万个watch，这对ZooKeeper而言也是压力山大啊。因此用ZooKeepe