大数据课程C5——ZooKeeper的应用组件-Toy模板网

这篇具有很好参考价值的文章主要介绍了大数据课程C5——ZooKeeper的应用组件。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

文章作者邮箱：yugongshiye@sina.cn 地址：广东惠州

▲ 本章节目的

⚪ 掌握Zookeeper的Canal消费组件；

⚪ 掌握Zookeeper的Dubbo分布式服务框架；

⚪ 掌握Zookeeper的Metamorphosis消息中间件；

⚪ 掌握Zookeeper的Otter分布式数据库同步系统；

一、Canal - 阿里

1. 概述

1. Canal是阿里巴巴于2013年1月正式开源的一个由纯Java语言编写的基于MySQL数据库Binlog实现的增量订阅和消费组件。

2. 目前项目主页地址为:https://github.Com/alibaba/canal 。由项目主要负责人，同时也是资深的开源爱好者agapple持续维护。

3. 项目名Canal取自“管道”的英文单词，寓意数据的流转，是一个定位为基于MySQL数据库的Binlog增量日志来实现数据库镜像、实时备份和增量数据消费的通用组件。

4. 早期的数据库同步业务，大多都是使用MySQL数据库的触发器机制（即Trigger）来获取数据库的增量变更。不过从2010年开始，阿里系下属各公司开始逐步尝试基于数据库的日志解析来获取增量变更，并在此基础上实现数据的同步，由此衍生出了数据库的增量订阅和消费业务——Canal项目也由此诞生。

5. Canal的工作原理相对比较简单，其核心思想就是模拟MySQL Slave的交互协议，将自己伪装成一个MySQL的Slave机器，然后不断地向Master服务器发送Dump请求。Master收到Dump请求后，就会开始推送相应的Binary Log给该Slave（也就是Canal）。Canal收到Binary Log，解析出相应的Binary Log对象后就可以进行二次消费了，其基本工作原理如下图所示。

大数据课程C5——ZooKeeper的应用组件,大数据,zookeeper,分布式

2. Canal Server主备切换设计

1. 在Canal的设计中，基于对容灾的考虑，往往会配置两个或更多个Canal Server来负责一个MySQL数据库实例的数据增量复制。

2. 另一方面，为了减少Canal Server的Dump请求对MySQLMaster所带来的性能影响，就要求不同的Canal Server上的instance在同一时刻只能有一个处于 Running状态，其他的instance都处于Standby状态，这就使得Canal必须具备主备自动切换的能力。

3. 在Canal中，整个主备切换过程控制主要是依赖于ZooKeeper来完成的，如下图所示：

大数据课程C5——ZooKeeper的应用组件,大数据,zookeeper,分布式

a. 尝试启动：每个Canal Server在启动某个Canal instance的时候都会首先向ZooKeeper进行一次尝试启动判断。具体的做法是向ZooKeeper创建一个相同的临时节点，哪个Canal Server创建成功了，那么就让哪个Server启动。以 “example”这个instance为例来说明，所有的Canal Server在启动的时候，都会去创建 /otter/canal/destinations/example/running 节点，并且无论有多少个Canal Server同时并发启动，ZooKeeper都会保证最终只有一个Canal Server能够成功创建该节点。

b. 启动instance：假设最终IP地址为10.20.144.51的Canal Server成功创建了该节点，那么它就会将自己的机器信息写入到该节点中去： {"active":true,"address":"10.20.144.51:11111","cid":1}并同时启动instance。而其他Canal Server由于没有成功创建节点，于是就会将自己的状态置为Standby，同时 /otter/canal/destinations/example/running节点注册Watcher监听，以监听该节点的变化情况。

c. 主备切换：Canal Server在运行过程中，难免会发生一些异常情况导致其无法正常工作，这个时候就需要进行主备切换了。基于ZooKeeper临时节点的特性，当原本处于Running状态的Canal Server因为挂掉或网络等原因断开了与ZooKeeper的连接，那么 /otter/canal/destinations/example/running节点就会在一段时间后消失。由于之前处于Standby状态的所有Canal Server已经对该节点进行了监听，因此它们在接收到ZooKeeper发送过来的节点消失通知后，会重复进行步骤1——以此实现主备切换。

4. 在主备切换设计过程中最容易碰到的一个问题，就是“假死”。所谓假死状态是指，Canal Server所在服务器的网络出现闪断，导致ZooKeeper认为其会话失效，从而释放了Running节点——但此时Canal Server对应的JVM并未退出，其工作状态是正常的。

5. 在Canal的设计中，为了保护假死状态的Canal Server，避免因瞬间Running节点失效导致instanc文章来源地址https://www.toymoban.com/news/detail-613424.html

到了这里，关于大数据课程C5——ZooKeeper的应用组件的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！