标签 github 下的文章

利用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而言也是压力山大啊。因此用ZooKeeper提供的诸多服 务如何来优化我们上面提到的两个主要问题呢?这里提出一种方案仅供参考。

方案示意图:

DB  —-> Config Center Services(css_agent + ZooKeeper)  —> App Node

在新方案中,我们要:
    保留 – 保留trigger脚本,作为业务数据变更的唯一的触发起点;
    摒弃 – 摒弃那个复杂的带来耦合的协议格式;
    借鉴 – 借鉴“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-000000000”,该节点的值为“ADD 1234567";
        – ZooKeeper将/ccs/foo_app/employee_info_tab节点的child事件发给所有watch该节点事件的应用节点;
        – 应用节点“取出”/ccs/foo_app/employee_info_tab节点下的children节点"item-000000000",并读取 其值,后续到DB的employee_info_tab中将id = 1234567的这条记录select出来,将该条记录更新到本地内存中。应用节点记录下处理过的当下节点id为"item-000000000";
        – DB业务表employee_info_tab又增加了两条记录,id分别为"7777777"和"8888888",经过上面描述的流程,/ccs /foo_app/employee_info_tab节点下会增加"item-000000001"和"item-000000002"两项; 应用节点最终会收到child事件通知。应用节点“取出”/ccs/foo_app/employee_info_tab节点下的所有 children节点并排序。之后,处理那些id号大于"item-000000000"的节点,并将当前节点id记录为“item- 000000002"。依次类推。

    * 过期处理
        – ccs_agent leader负责定期扫描ZooKeeper中/ccs下各个表节点下的子项,对于超出过期时间的item进行删除处理。

    * 应用节点重启
        -  应用节点重启后,会首先从db读取最新信息,并记录启动时间戳;
        -  应用节点重启后,在收到zookeeper的数据变更事件后,会根据当前时间戳与变更表节点下的item创建时间进行比较,并仅处理比启动时间戳新的 item的数据。
   

这个方案主要利用了ZooKeeper提供的leader election服务以及sequence节点的特性,几点好处在于:

    – 串行通知变为并行通知,且通知到达及时;
    – 变更数据的Push模式为Pull模式,降低了或去除了诸多耦合,包括:
            1) 去除trigger脚本与表字段及字段顺序的耦合;
            2) 去除应用节点与表字段顺序的耦合;
            3) 降低应用节点与表字段构成的耦合。
    – 应用节点无需复杂的包解析,简化后期维护。

当然为了该方案新增若干网元会给产品部署和维护带来一些复杂性,这算是不足之处吧。

四、Demo

这里有一个600多行代码的Demo,模拟新方案中几个角色:
    DB – trigger_sim.py
    应用节点 – app.c
    ccs_agent – ccs_agent.c

模拟的步骤大致如下(单机版):

a) 启动ZooKeeper
    $> zkServer.sh start
    JMX enabled by default
    Using config: /home1/tonybai/.bin/zookeeper-3.4.5/bin/../conf/zoo.cfg
    Starting zookeeper … STARTED

b) 启动ccs_agent
    $> ccs_agent
    This is [ccs-member0000000037], i am a leader
    /ccs node exists
    /ccs/employee_info_tab node exists
    /ccs/boss_info_tab node exists
    trigger listen thread start up!
    item expire thread start up!

c) 启动app

d) 使用trigger_sim.py模拟DB触发trigger
        $> trigger_sim.py employee_info_tab ADD 1234567

可以看到ccs_agent输出结果如下:
    table[employee_info_tab], oper_type[ADD], id[1234567]

app的输出如下:
    child event happened: type[4]
    item-0000000015
    employee_info_tab: execute [ADD 1234567]

大约30s后,ccs_agent会输出如下:
    [expire]: employee_info_tab: expire [item-0000000015]

模拟步骤在README里有写。这里仅是Demo代码,存在硬编码以及异常处理考虑不全面的情况,不要拍砖哦。

buildc 0.3.0版本发布

buildc正式在项目中应用以来,我们收到了许多同事针对buildc演进的意见和建议。其中确实有些易用性的问题是在最初设计时未考虑周全的,尤其是.buildc.rc中的配置,同事们对该文件的配置已经“怨声载道”了。

.buildc.rc是用来配置某开发者在开发过程中使用的第三方库所在subversion repository信息的,例如:

a_repository = ('SVN库地址', '本地缓存路径',
              [
                  # 格式:[(“第三方库名称”, “库版本”, “特征库文件”), …]
                  ('libevent', '2.0.10', 'lib/libevent.a'),
                  ('instantclient', '10.2.0.5.0', 'lib/libnnz10.so'),
                  …
              ]
            )
b_repository = ('SVN库地址', '本地缓存路径', [])
c_repository = ('SVN库地址', '本地缓存路径', [])

external_repositories = [
                        a_repository,
                        b_repository,
                        c_repository,
                        …
                   ]

这里面需要维护最多、最频繁的就是各个repository中具备的第三方库名、版本号。开发者所开发的项目所依赖的第三方库信息发生变化,不仅仅需要修 改project下的buildc.cfg文件,还可能要修改.buildc.rc,大家维护起来确实体验不好,会多耗费一些工作量。

针对这个主要问题,我们决定对buildc进行一次较大范围的重构,重构后的版本定为buildc 0.3.0版本。以下是buildc 0.3.0版本的主要改动点:

一、简化.buildc.rc的配置,重新定义cache相关命令的语义

0.3.0及以后版本的.buildc.rc只需配置repository的地址信息以及cache缓存的本地路径信息,无需再提供repository 里面具体的第三方库以及版本号信息了,这样一来,大多数情况下,project依赖的第三方库发生变更,都无需修改.buildc.rc了。

a_repository = ('SVN库地址', '本地缓存路径')
b_repository = ('SVN库地址', '本地缓存路径')
c_repository = ('SVN库地址', '本地缓存路径')

external_repositories = [
                        a_repository,
                        b_repository,
                        c_repository,
                        …
                   ]

随之而变的是buildc cache相关命令的语义,0.3.0中cache相关命令的语义如下:

* buildc cache init - 生成.buildc.repository,该文件是svn库的目录结构文件,相当于一份svn repository内部的地图,repository中存放的各种第三方库以及版本均在该文件中索引;如果该文件已经存在,命令执行的结果为:提示已存在。

* buildc cache upgrade – 根据.buildc.rc的最新更新,重新生成.buildc.repository文件,并将该文件中所有lib本地的 Revision号置为none。该文件并不会执行本地cache的library的真实更新操作。

* buildc cache update  - 
    1. 如果.buildc.rc已经修改,但没有执行buildc cache upgrade,update会对比本地缓存库信息与对应的.repository文件中的同名lib信息,如果不一致,则提醒执行upgrade。
    2. 如果.buildc.repository是新生成的,所有lib本地的Revision号均是none,则提示没有要更新的本地缓存库;
    3. 如果某个项目已经download了自己依赖的库,那update将比对svn库中和本地库的revision差异,并下载最新库版本。并修改.buildc.repository中对应库的本地revision number。

* buildc cache remove – 将.buildc.repository中对应库的本地revision number都置为none,并删除本地缓存的库文件。

二、重新定义config make的语义

前面提到了,在执行buildc cache init时,buildc只是负责生成.repository文件,而并不真实执行库文件的下载和缓存。那何时真正下载呢?答案是在执行buildc config make时。这里颇有些“lazy evaluate”的味道,需要时再“download and cache it"。

* buildc config make

1. 如果.buildc.rc已经修改,但没有执行buildc cache upgrade,config make会对比本地缓存库信息与对应的.repository文件中的同名lib信息,如果不一致,则提醒执行upgrade。
2. 如果.buildc.rc是新生成的,或执行cache upgrade后的,config make会根据project对应的buildc.cfg中配置的第三方库,在.buildc.repository中查找是否存在(包括对应的版本 号),如果存在,则从subversion server端自动下载;否则提示出错。
3. 如果本地缓存中某个库文件不存在,buildc config make会检测到,并自动下载该库,并cache起来。
4. 如果subversion端某个库的svn revision号发生的更新,buildc config make会检测到,并下载最新的版本。

总之一切都是在buildc config make时来完成的,按需下载或更新,这样你甚至无需进行手工的library Cache维护。

三、转向OO范型

实现buildc 0.3.0的小同事(wtz1989227@gmail.com)对OO情有独钟,因此在这个版本中,他将以前的结构化代码做了大幅度调整,并用OO的方 式进行了重构。按照wtz的思路,这次改造比较初级,OOD做得还不够充分,以后慢慢调整。实际代码中反映出来的情况也的确是这样。

四、buildc 0.2.3发布

在将buildc 0.3.0代码merge到trunk之前,我创建了buildc-0.2的maintain branch,虽然理论上buildc 0.3.0在功能和配置方面与buildc 0.2.x版本是兼容的,但毕竟代码调整幅度较大。另外建议大家都转移到0.3.0这个最新版本上来,buildc-0.2分支顶多做一些bugfix, 不会再有新feature添加进去了。

昨天在发布buildc 0.3.0的同时,还发布了buildc-0.2的一个Bugfix版 – buildc 0.2.3,该版本主要做了如下一些fix:

  * 执行cache upgrade时增加对.buildc.rc中repository特征文件存在性的检查;
  * 执行config make时增加对Make.rules文件是否为空的判断;
  * 执行pack source时,添加VERSION文件,记录打包的上下文信息。

五、其它

考虑到github的活跃度远远高于google code,加上google code最近访问十分不稳定,因此之前就将buildc(还有cbehavelcut以及我的实验代码库)fork了一份到github上了,也攒攒 github上人气,因此这次buildc 0.2.3和buildc 0.3.0的代码还要发布到github上一次。git工具平时用的少,尤其是提交代码到github,这次算入门了。

* 代码远程提交
用git remote add一个github的remote repository后,就可以使用git push origin master将本地的commit推送到github上了。

* 打tag,并推送tag

   — 查看Tag的git命令是git tag
   — 本地打tag,用这个命令: git tag -a v0.2.3 -m"0.2.3 released"
   — 推送Tag到remote repository:git push –tags origin master,不加–tags是无法推送tag的。

* branch操作
  — 查看branch:git branch
  — 创建branch:git branch buildc-0.2
  — 推送branch:git push origin buildc-0.2
  — 本地切换branch:git checkout buildc-0.2

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats