一、起源：
早期，阿里巴巴B2B公司因为存在杭州和美国双机房部署，存在跨机房同步的业务需求。不过早期的数据库同步业务，主要是基于trigger的方式获取增量变更，不过从2010年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅&消费的业务，从此开启了一段新纪元。
基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了mysql
二、用来做啥的
- 数据库镜像
- 数据库实时备份
- 多级索引 (卖家和买家各自分库索引)
- search build
- 业务cache刷新
- 价格变化等重要业务消息
三、原理
1. canal把自己伪装成了mysql 的slave，同步mysql的数据
四、架构
说明：
- server代表一个canal运行实例，对应于一个jvm
- instance对应于一个数据队列 （1个server对应1..n个instance)
instance模块：
- eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
- eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作)
- eventStore (数据存储)
- metaManager (增量订阅&消费信息管理器)
五、canal的坑
1.client和server需要在同一个子网？能通信不就行了
2.canal重启的问题
3. mysql重启
4. mysql宕机
5. 流式API，get,ack可能带来重复消费的问题
6. 不同vpc问题
六、canal如何做HA
HA的大致流程
- canal server要启动某个canal instance时都先向zookeeper进行一次尝试启动判断 (实现：创建EPHEMERAL节点，谁创建成功就允许谁启动)
- 创建zookeeper节点成功后，对应的canal server就启动对应的canal instance，没有创建成功的canal instance就会处于standby状态
- 一旦zookeeper发现canal server A创建的节点消失后，立即通知其他的canal server再次进行步骤1的操作，重新选出一个canal server启动instance.
- canal client每次进行connect时，会首先向zookeeper询问当前是谁启动了canal instance，然后和其建立链接，一旦链接不可用，会重新尝试connect.
- Canal Client的方式和canal server方式类似，也是利用zokeeper的抢占EPHEMERAL节点的方式进行控制.
七、canal server在什么时候删除数据?
- 收到ACK结束以后
八、EventStore的配置方式
1. file 2. zk 3. memory
九、canal在rds中的问题
1. 账号权限问题
2. binlog被删除的问题
3. 主备切换导致的问题
解决方式：升级canal到最新版本
https://github.com/alibaba/canal/wiki/aliyun-RDS-QuickStart
参考
http://www.cnblogs.com/w10234/p/6672133.html
https://blog.csdn.net/tanga842428/article/details/59098828
位点问题排查
https://github.com/alibaba/canal/wiki/FAQ
https://blog.csdn.net/my201110lc/article/details/78836270