工具类服务
编辑部专用服务
作者专用服务
基于Zookeeper分布式搜索引擎系统的配置文件自动更新方法、装置及系统
文章研究并提供了一种基于zookeeper分布式搜索引擎系统的配置文件自动更新方法.通过自动检测master节点内是否形成了新的配置文件,并在检测到形成了新的配置文件后主动上传到zookeeper,并下发到各slave节点加载到内存中用于搜索任务的处理.无需管理人员在发现master节点形成了新的配置文件之后,重启master节点才将新的配置文件上传,显然降低了master节点与slave节点间配置文件同步的繁琐性,提高了设备的智能性,降低了同步成本.
作者单位：
中兴通讯股份有限公司
年，卷(期)：
机标分类号：
在线出版日期：
本文读者也读过
相关检索词
万方数据知识服务平台--国家科技支撑计划资助项目（编号：2006BAH03B01）(C)北京万方数据股份有限公司
万方数据电子出版社应用项目中都会有一些配置信息，这些配置信息数据量少，一般会保存到内存、文件或者数据库，有时候需要动态更新。当需要在多个应用服务器中修改这些配置文件时，需要做到快速、简单、不停止应用服务器的方式修改并同步配置信息到所有应用中去。本篇文章就是介绍如何使用ZooKeeper来实现配置的动态同步。
在《》一文中可以看到hive为了支持并发访问引入了ZooKeeper来实现分布式锁。参考《》一文，ZooKeeper还可以用作其他用途，例如：
数据发布与订阅（配置中心）
命名服务(Naming Service)
分布式通知/协调
集群管理与Master选举
分布式队列
一些在线系统在运行中，需要在不停止程序的情况下能够动态调整某一个变量的值并且能够及时生效。特别是当部署了多台应用服务器的时候，需要能够做到在一台机器上修改配置文件，然后在同步到所有应用服务器。这时候使用ZooKeeper来实现就很合适了。
数据发布与订阅
发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。
使用ZooKeeper的发布与订阅模型，可以将应用中用到的一些配置信息放到ZK上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的。这样的场景适合数据量很小，但是数据更新可能会比较快的需求。
配置存储方案
配置文件通常有如下几种保存方式：
将配置信息保存在程序代码中这种方案简单，但每次修改配置都要重新编译、部署应用程序。显然这种方案很不方便，也不可靠，更无法做到修改的实时生效。
将配置信息保存在xml文件或者属性文件中在参数信息保存在xml或者属性文件中，当需要修改参数时，直接修改 xml 文件。这样无需重新编译，只需重新部署修改的文件即可。但然后对所有的应用进行重新部署。这样做的缺点显而易见，要往上百台机器上重新部署应用，简直是一个噩梦。同时该方案还有一个缺点，就是配置修改无法做到实时生效。修改后往往过一段时间才能生效。
将配置信息保存在数据库中当需要修改参数时，直接修改数据库，然后重启分布式应用程序，或者刷新分布式应用的缓存。尽管这种做法比以上两种方案简单，但却面临着单点失效问题。如果数据库服务器停机，则分布式应用程序的配置信息将无法更新。另外这种方案的配置修改生效实时性虽然比第二种方案好些，但仍然不能达到某些情况下的要求。
基于ZooKeeper的配置信息同步方案
如果使用ZooKeeper来实现，就可以直接把配置信息保存到ZooKeeper中，或者把属性文件内容保存到ZooKeeper中，当属性文件内容发生变化时，就通知监听者如应用程序去重新读取配置文件。
在网上搜索了一下，很能找到好用的现成的代码实现。有的基于ZooKeeper来扩张jdk的hashmap来存储配置参数，如：，也有人直接实现了一个基于java并发框架的工具包，如：。
注意:以下部分文字和图来自：
基于ZooKeeper的特性,借助ZooKeeper可以实现一个可靠的、简单的、修改配置能够实时生效的配置信息存储方案,整体的设计方案如图：
整个配置信息存储方案由三部分组成:ZooKeeper服务器集群、配置管理程序、分布式应用程序。
ZooKeeper服务器集群存储配置信息,在服务器上创建一个保存数据的节点(创建节点操作);配置管理程序提供一个配置管理的UI界面或者命令行方式,用户通过配置界面修改ZooKeeper服务器节点上配置信息(设置节点数据操作);分布式应用连接到ZooKeeper集群上(创建ZooKeeper客户端操作),监听配置信息的变化(使用获取节点数据操作,并注册一个watcher)。
当配置信息发生变化时，分布式应用会更新程序中使用配置信息。
找到一个淘宝工程师写的实现方式， 代码见：
借助 ZooKeeper我们实现的配置信息存储方案具有的优点如下:
简单。尽管前期搭建ZooKeeper服务器集群较为麻烦,但是实现该方案后,修改配置整个过程变得简单很多。用户只要修改配置,无需进行其他任何操作,配置自动生效。
可靠。ZooKeeper服务集群具有无单点失效的特性,使整个系统更加可靠。即使ZooKeeper 集群中的一台机器失效,也不会影响整体服务,更不会影响分布式应用配置信息的更新。
实时。ZooKeeper的数据更新通知机制,可以在数据发生变化后,立即通知给分布式应用程序,具有很强的变化响应能力。
本文参考了网上的一些文章，给出了基于ZooKeeper的配置信息同步方案,解决了传统配置信息同步方案的缺点如实时性差、可靠性差、复杂等。
转载自，作者：
阅读(...) 评论()本帖子已过去太久远了，不再提供回复功能。利用ZooKeeper服务实现分布式系统的配置数；很多时候，一旦习惯了某些事情，也就习惯了它们的恶；CTonyBai；一、痼疾难解；我们目前的业务配置数据同步方案；方案涉及两个角色C数据库(DB)与应用节点（ap；所有的业务配置数据均统一存储在DB中；；应用节点在启动后从DB中读取最新业务配置数据；；应用节点运行过程中，如果DB中的业务配置数据发生；曾几何时
利用ZooKeeper服务实现分布式系统的配置数据同步
很多时候，一旦习惯了某些事情，也就习惯了它们的恶劣，习惯了它们的丑陋，习惯了它们“赋予”你的各种痛苦。
C Tony Bai
一、痼疾难解
我们目前的业务配置数据同步方案。简单描述这个方案如下：
方案涉及两个角色C数据库(DB)与应用节点（app_node)；
所有的业务配置数据均统一存储在DB中；
应用节点在启动后从DB中读取最新业务配置数据；
应用节点运行过程中，如果DB中的业务配置数据发生变更（增/删/改），DB中的触发器(trigger)将会执行。在触发器的脚本中，触发器将会【串行】地与每个应用节点建立TCP链接，并将业务配置表的变更信息发给各个应用节点。应用节点会接收并【解析】触发器发过来变更数据包，并同步到自己的本地内存中。这样就达到了运行时更新配置的目的。
曾几何时，在那个还没有集群化，没有分布式的时代，它还是一个不错的方案，至少在线上没有暴露出太多问题，它也不在我们关注的重点范围之内。但随着集群化、分布式的新版本的到来，那一大坨遗留的代码就变得格外让人不顺眼，同时问题也随之在线上暴露开来了。 上面我用【】标记了两个关键词：“串行”和“解析”。这两个词隐含有这个方案的两个主要问题。
“串行”C意味着每一次DB的业务配置数据变更，trigger脚本都要逐个与应用节点建立链接并收发数据。当应用节点逐渐增多时，每一次业务数据同步都会相当地耗时。尤其是当某个应用节点所在主机出现问题时，到该节点链接建立的过程会阻塞，导致整个业务配置数据同步的时间达到无法忍受的地步。
“解析”C我们自定义了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而言也是压力山大啊。因此用ZooKeeper提供的诸多服务如何来优化我们上面提到的两个主要问题呢？这里提出一种方案仅供参考。
方案示意图：
DB ―-&Config Center Services(css_agent + ZooKeeper) ―& App Node
在新方案中，我们要：
保留C保留trigger脚本，作为业务数据变更的唯一的触发起点；
摒弃C摒弃那个复杂的带来耦合的协议格式；
借鉴C借鉴“Push -& Pull”的数据获取方式。
新方案中除了DB、应用节点(app_node)外，新增加了一个角色Config Center Services(缩写为ccs），ccs由ZooKeeper + ccs_agent的集群组成。简单起见，每个ZooKeeper节点上部署一个ccs_agent。这些角色之间的数据流和指令流关系，即该方案的原理如下：
ZooKeeper集群启动；
ccs_agent启动，利用ZooKeeper提供的leader election服务，选出ccs_agent leader。ccs_agent leader启动后负责在ZooKeeper中建立业务配置表node，比如：表employee_info_tab对应的node路径为“/ccs /foo_app/employee_info_tab”；
ccs_agent启动后会监听一个端口，用来接受DB trigger向其发起的数据链接；
应用节点启动，监听ZooKeeper上所有（数量有限的）业务配置表node的child event； 数据变更
DB中某业务表比如employee_info_tab增加了一条id为&1234567&的记录；
触发器启动，向ccs_agent cluster中任意一个可用的节点建立链接，并将数据包“^employee_info_tab|ADD|1234567$&发送给 ccs_agent；
ccs_agent收取并解析trigger发来的数据包，在对应的/ccs/foo_app/employee_info_tab下建立ZOO_SEQUENCE类型节点“item-”，该节点的值为“ADD 1234567&；
ZooKeeper将/ccs/foo_app/employee_info_tab节点的child事件发给所有watch该节点事件的应用节点；
应用节点“取出”/ccs/foo_app/employee_info_tab节点下的children节点&item-&，
并读取其值，后续到DB的employee_info_tab中将id = 1234567的这条记录select出来，将该条记录更新到本地内存中。应用节点记录下处理过的当下节点id为&item-&； DB业务表employee_info_tab又增加了两条记录，id分别为&7777777&和&8888888&，经过上面描述的流程，/ccs /foo_app/employee_info_tab节点下会增加&item-&和&item-&两项；应用节点最终会收到child事件通知。应用节点“取出”/ccs/foo_app/employee_info_tab节点下的所有 children节点并排序。之后，处理那些id号大于&item-&的节点，并将当前节点id记录为“item- &。依次类推。 过期处理
ccs_agent leader负责定期扫描ZooKeeper中/ccs下各个表节点下的子项，对于超出过期时间的item进行删除处理。
应用节点重启
应用节点重启后，会首先从db读取最新信息，并记录启动时间戳；
应用节点重启后，在收到zookeeper的数据变更事件后，会根据当前时间戳与变更表节点下的item创建时间进行比较，并仅处理比启动时间戳新的 item的数据。
这个方案主要利用了ZooKeeper提供的leader election服务以及sequence节点的特性，几点好处在于：
串行通知变为并行通知，且通知到达及时；
变更数据的Push模式为Pull模式，降低了或去除了诸多耦合，包括：
去除trigger脚本与表字段及字段顺序的耦合；
去除应用节点与表字段顺序的耦合；
降低应用节点与表字段构成的耦合。
应用节点无需复杂的包解析，简化后期维护。
三亿文库包含各类专业文献、中学教育、行业资料、专业论文、生活休闲娱乐、外语学习资料、各类资格考试、应用写作文书、幼儿教育、小学教育、文学作品欣赏、16利用的配置ZooKeeper服务实现分布式系统数据同步等内容。　
　利用ZooKeeper简单实现分布式锁_计算机软件及应用_IT/计算机_专业资料。利用...会的一个软件项目,他为大型分布式计算提供开源的分布式 配置服务、同步服务和命名... 　分布式文件使用场景_计算机软件及应用_IT/计算机_专业...场景三:配置管理。在分布式系统里,我们会把一个服务...器同步 zookeeper 里的配置文件, zookeeper 服务也会... 　分布式服务框架 Zookeeper - 管理分布式环境中的数据_计算机软件及应用_IT/计算机_专业资料。本文介绍的 Zookeeper 是以 3.2.2 这个稳定版本为基础,Zookeeper 的安装... 　开发人员不必过多地 纠结在分布式系统编程难于处理的同步和一致性问题上, 你可以使用 Zookeeper 提供的现成(off-the-shelf)服务来实现分布式系统的配置管理, 组... 　case 中, 例如命名、 配置管理、 同步和组服务等...个协调分布式环境中各子系统T间共享状态数据的基础...3. 为什举使用 ZooKeeper 目前有关亍分布式 Session... 　本文将从使用者角度详细介绍 Zookeeper 的安装和配置文件中各个配置项的意义,...一些数据管理问题,如:统一命名服务、状态同步服务、 集群管理、分布式应用配置项... 　ZooKeeper是Hadoop的开源子项目,在分布式系统架构中大量的被运用,从而减少分布式架构的复杂度;典型的运用场景包括: 数据发布/订阅、负载均衡、命名服务、分布式协调/通知... 　是以 Fast Paxos 算法为基础,实现同步服务,配置维护和命名服务等 分布式应用。 ...在编程上, ZooKeeper 设计很简单,所使用的数据模型风格很像文件系统的目录树结构... 　为什么不使用ZooKeeper构建云平台发现服务_互联网_IT/计算机_专业资料。为什么不使用...的核心 实现算法 Zab,就是解决了分布式系统下数据如何在多个服务之间保持同步...}