揭秘中间件集成的通常过程【Canal为例】

数据同步背景

为何要作数据同步？由于数据不少，还要共享或作它用。举个栗子，你从移动硬盘拷贝一份小小电影到你的Macbook上赏析，也叫数据同步。但系统不比你的单纯，它使用的场景千奇百怪。数据同步，无论爱与不爱，你总会碰见，它会在某个时间等你，不见不散。

哎，不就是A到B么，一个管道，罩得住。

Canal简介

要在有限的时间里漂亮的完成工做，有时候你关注的并不必定是问题中心，深挖学习了binlog的同步方式，并不会对你的工做进度有任何改善。将它加入到研究列表中，空闲的时间去学习更佳，不必非要把头闷在水里憋气去体验窒息的味道。好了，问题的中心数据同步，已经由阿里的工程师替你完成了，就叫Canal，解决的是最经常使用的MySQL数据库同步到别处的问题。今天咱们谈一下Canal集成，但不谈Canal细节实现。周边建设别人不舍得告诉你，小姐姐味道和你聊。

Canal是将本身假装成一个MySQL从库从其余真正的MySQL库上拉取信息，说白了就是实现了MySQL的一套协议，数据拿过来以后，想怎么把玩就怎么玩喽。东西是好东西，但github上的wiki文档让人看的昏昏欲睡，既然是谈架构，那咱们就聊一下如何才能让工程师放心的使用你的Canal。

数据格式

简单说下Canal的数据格式，根据github的官方文档就可以简单的RUN起来。Canal可以同步大多数DCL、DML、DDL，咱们一般也就关心INSERT、UPDATE、DELETE引发的变化。那Canal解释的数据是什么样子呢，咱们能够用一张图来讲明。

能够看到UPDATE同时包括变动前和变动后的值，须要的信息就都有了。有了这些数据，上天入地，无所不能。

一个通用的架构模式就是只考虑输入和输出。使用者大多数并不关心你的系统是怎么实现的，你们都很忙，并且并不必定都有兴趣。他只须要你告诉他最终的使用方式和输出格式便可。

总体高可用

那么开发使用中有哪些元素须要参与呢？咱们一样上一张图(仅考虑集群主从模式，单机和M/M不谈)。

很Easy是否是？ZK控制着HA，同时记录消费的消费进度，怎么看都和Kafka之流一个套路。但这里有几点要说明：

1. 为了保证binlog正常拉取，Canal服务器同时只有一台工做，其余都是影子 lol
2. 为了保证消费能正常进行，Client端同时只有一台可以工做，其余都是影子 lol
3. binlog推荐使用ROW模式，但有可能一个update语句挤爆你的内存、打碎你的蛋蛋
4. Canal自己没有持久化能力，很是耗内存

咱们接下来按照顺序模拟它们的死亡。考虑下面一张图。

红色的区块都是可能死亡的点，ZK会死（固然它坚挺的很），MySQL会死，至于Canal，也确定不能免俗，咱们要让它的死轻如鸿毛。

小姐姐，提醒，架构要考虑到每个交互场景和极端状况。准备的越细，觉睡的越香。除了让挑战你的无聊者碰一鼻子灰（对，就是那些成天将高可用挂在嘴上的货），也能节省更多时间研究些更有意义的事情。

ZK当机

ZooKeeper那么健壮，为何还要模拟其当机呢？由于不排除机房断电的可能。为何咱们首先谈到ZK？从图中能够看到Zk死亡对系统的影响是巨大的。固然这仅仅是几率而已，最终会推断出SLA服务质量，知足需求便可。

固然不排除有某些强迫症的外部因素影响你去作它的高可用。除了分机房，你能够能够在代码中进行集成，好比ZK死亡，咱们去直连Canal。你要考虑开发成本和达到的效益是否合适。

有些公司在屁都没作出来以前，就特别洁癖的关注低几率事件，问题自己倒成了次要的了。这种公司是有问题的，尽可能去说服吧。

因此若是ZK当机问题占用你的工做量，主要是其余人的认知问题。

Canal当机

Canal集群模式已经经过ZK作了HA，你要作的，就是模拟一遍。包括：

1. 当机一台，是否有其余实例顶上来
2. 所有当机，上线一台后是否能正常运行
3. 长时间下线后，忽然上线是否有其余问题？
4. 内存问题。canal很是耗内存，能够配置参数使其不溢出，但会产生阻塞。

Client当机

Client的当机实际上是无所谓的。但因为实现的方式千奇百怪，也会产生千奇百怪的事情。本部分主要是使用方式问题，能够备注在注意事项里。咱们经过代码来讲明：

1. 代码有两层while循环，若是只有一层的话，会出问题的(想想问什么)
2. 代码有ACK确认机制，代码显示的进行了确认和回滚。但若是你的处理是放在多线程里，那就有可能漏掉消息
3. 消息有batch，因此不可避免会出现重复消费的状况，你的业务支持幂等么？

MySQL当机

1. MySQL从新上线后Canal是否可以正常拉取binlog?
2. 主从切换后，是否须要修改Canal? 怎么补数据？

外围扩展

要将Canal用起来的话，它自己只能算是一个半成品。只有给它加上翅膀，它才可以自由飞翔。

MQ

考虑到Canal的堆积能力并不强。堆积数据到10W+时，速度会变慢，并会出现假死现象。另一个场景，就是canal忽然上线，这时候已经延后binlog不少了，从新链接后会一次性获取全部数据，卡到死为止～。

对于第一个场景，一个MQ介入是很是有必要的。Kafka等消息队列的堆积能力已经家喻户晓，咱们要作的就是将Canal的数据进行一次转发。之后的客户端，打交道的就只有MQ了。MQ介入后，有如下好处：

1. 得到很是好的堆积能力，能够延后消费
2. 可以方便的获得积压数据，进行监控报警
3. 不比引入Canal客户端，客户端开发只与MQ打交道便可
4. MQ支持顺序消息，对于无时序数据而言，非顺序消息能增长处理能力

监控报警

每一个节点都会出问题，因此每一个节点都须要监控。监控系统也是每一个公司的工具链，你可能须要写一些zabbix或者telegraf脚本进行数据收集（监控系统咱们后续文章介绍）。

进程监控

监控各组件是否存活，java程序发生内存溢出死亡的几率仍是很大的。若是想要进程死亡后自动重启，能够考虑采用supervisor组件。

BTW：若是你找不到进程的死亡缘由，执行dmesg命令，大几率会看到死亡缘由。

业务监控

1. MySQL binlog位置监控（show master status;）。
2. Canal到MQ的Sink消费位点监控。
3. 业务消费端对于MQ的消费延迟监控(delay)。

自动部署

一个好的持续集成工具可以大量减小上线时间和故障响应时间。此部分与各公司的工具链有关。好比可使用ansible等命令行工具，也可使用jenkins等。

这部分的工做量仍是比较大的，尤为是当组件增多。有几个容易忽略的点须要考虑：

1. MySQL主从切换时，Canal的配置是否须要变更
2. 当单MySQL实例库表过多时，Canal是否须要分开部署，维护其拓扑结构
3. 各组件启动顺序问题，是否代码作了兼容可以支持
4. 数据同步需求是否线性增加，对应Topic的粒度支持

迭代思路

一个使用了第三方组件的数据同步中间件产品的建设过程，大致是分为如下6个阶段的。不少人还停留在搭起来就OK的阶段。除了搭建验证读源码或者是本身造轮子，还有不少额外的事情要作，这才是架构师应该关注的事情。

基础搭建使用

能够根据文档完成一个quickstart，并能初步应用到业务中。此时的服务基本上是裸跑，有比较多的风险。

API封装易用

根据本身的使用场景剔除或者增长部分功能，根据本身公司的编码和代码风格，编写定制易用的API。这多是一个适配器，也多是一个spring-starter等。还有一些坑须要进行屏蔽等，好比开源版本的Canal没有GTID等，呵呵。这个时候适当读下源码是很是有必要的。

总体高可用和应急方案

对于一个重量级的中间产品，此部分的重要度是不言而喻的。数据交互节点，每个都应该是不信任的。仔细CHECK数据交互中的每个节点，找出突发状况的应急方案。有条件的，须要线上反复演练，确保系统总体达到高可用。

报警运维机制

完成责任划分和应急处理人员，确保每一条报警信息都能快速响应，将故障影响面下降到最低。此部分涉及流程机制问题，做为架构师是有责任推动其完成的。

内部文档与系统集成

为了达到快速响应的目的，同时让产品更加平滑的加入到公司技术栈中，须要将其集成到公司内部系统中。好比定制的监控系统、继续集成系统等。同时，为了减小其余伙伴的学习使用成本，一个浅显易懂的文档也是必要的（不是doc哦）。对于使用中容易形成故障的点，也要指出，并非每一个人都和你同样聪明能干。

宣传应用检验阶段

若是对你的系统有信心，最大规模的使用去检验其鲁棒性是极好的。一些宣传和支持是必要的，相信到了此阶段，有大量的使用案例，不断的培养用户，对你系统的怀疑会不攻自破。

总结

架构只是作技术么？这是狭义上的理解，技术是个敲门砖。广义上的架构包括技术、流程和人。转变这个观念，愿你的事业更上一层楼。

本篇文章稍有滞后，canal最新版已经本身支持mq。