本节目录
- 1、Canal 位点管理（日志管理器）
- 1.1 类图
- 1.2 日志管理器使用方法
- 2、MySQL GTID 扫盲
正如上文提到的那样，在 Canal Instance 启动的时候，首先会查询日志管理器中查找上一次的同步位点，如果没有查询到，则默认会从最新的位点开始同步，但如果每一次启动Instance都从最后开始同步，其数据完整性无法保证，正确的做法是在数据同步的过程中应该记录位点并持久化，重新启动后按照继续从上一次的位置继续同步，实现真正的增量同步。
本文就是来详细探讨 Canal的几个日志管理器，并来探究一下MySQL的GTID机制。
1、Canal 位点管理（日志管理器）
1.1 类图
整个日志管理器由接口 CanalLogPositionManager定义，主要定义两个方法：
- LogPosition getLatestIndexBy(String destination)
根据destination获取同步位点，即在Canal Instance 中同步进度是以源实例为最小维度的。 - void persistLogPosition(String destination, LogPosition logPosition)
持久化同步位点。
Canal 中提供了7种位点管理机制，分别如下：
- MemoryLogPositionManager
同步位点存储在内存中，即存放在 Map<String, LogPosition> positions 中，通常用于测试或结合其他位点管理，用来提高性能。 - ZooKeeperLogPositionManager
同步位点存储在zookeeper中，是主流的分布式存储方案。 - MetaLogPositionManager
Canal中的元数据存储方式，即位点信息与元数据存放在一起。 - MixedLogPositionManager
混合日志位点管理器，主要是内存与Zookeeper的混合方式，在存储位点时先存入内存，然后用线程池异步存储到zookeeper中。 - FileMixedLogPositionManager
基于内存与本地文件的混合日志管理器，存储位点时首先存入内存，然后定时同步到文件中。 - PeriodMixedLogPositionManager
带定时功能的基于内存与zookeeper的混合日志管理器，存储位点时先写入内存，然后定时同步到zookeeper。 - FailbackLogPositionManager
待failback机制的日志位点管理器，即可以创建准备两种日志管理器，例如在构建时可以将 ZooKeeperLogPositionManager 当为主管理器，基于 FileMixedLogPositionManager 当备用日志位点管理器，在写入日志位点时，尝试写入主日志管理器，如果抛出异常，则使用备用日志管理器；查询位点时先查主日志
管理器，如果未查到，则查备用日志管理器。
1.2 日志管理器使用方法
由于Canal日志管理器的实现比较简单，这里就不一一去看源码了，那这里就重点介绍一下其使用方法。
CanalInstanceWithManager#initLogPositionManager
从这里可以看到，Canal 提供了 indexMode 属性来指定使用哪种日志管理器，其可选项：
- MEMORY
内存 - ZOOKEEPER
基于zookeeper，使用该模式还需要通过 zkClusters 设置 zk 集群的地址。 - MIXED
混合模式，基于内存+Zookeeper + Period，即定时存储到 zookeeper 中，使用的实现类为MixedLogPositionManager，默认为每隔1s持久化一次。 - META
基于元数据的管理模式。 - MEMORY_META_FAILBACK
基于内存与元数据的fallback，其中主日志管理器为 MEMORY。
在生产环境，通常建议使用 MIXED，基于内存与Zookeeper的混合模式。
2、MySQL GTID 扫盲
在MySQL5.6.x中引入了GTID机制，用于优化主从同步机制，本文不打算详细介绍GTID的方方面面，只是初步认识GTID，方面在后续实现数据同步方面思考数据一致性如何保证等方案时具备必要的基础。
首先我们可以通过如下命令查看与gtid相关的属性。
主要的变量的含义如下：
- gtid_executed
当前MySQL实现已经执行过的事务。在开启GTID模块时每执行一个事务会产生一个全局唯一的事务ID。再每一台MySQL实例上执行的事务何止上亿，这个字段要存储所有已执行的的事务ID，怎么存储能节省空间就是一个需要解决的问题，稍后再进行展开说明。 - gtid_executed_compression_period
在MySQL5.7版本专门引入了一个系统表：mysql.gtid_executed，gtid_executed_compression_period 参数就是设置每执行多个事务，对这个表进行压缩，默认值为1000。 - gtid_mode
是否开启gtid模式。 - gtid_purged
已不在binlog日志中的事务ID，Mysql并不会永久存储binlog日志，而是通过 expire_logs_days 设置过期时间，单位为天，默认为10天。
一个GTID由两部分组成：server id uuid 与递增序号，两者之间用英文冒号隔开，例如上图中的：1f0eee4c-a66e-11ea-8999-00dbdfe417b8:1。
再来回到 gtid_executed 的存储问题上，为了减少存储空间，连续的gtid可以用进行合并，例如 1f0eee4c-a66e-11ea-8999-00dbdfe417b8:1-10，表示连续代表1-10个事务。
GTID的生成有自动递增与手动执行模式，自动递增模式可以在单个Server集群中保证有序，即GTID值越大，说明事务越后执行，但如果进行了人工干预，GTID就不是越大越先执行了，举例如下：
通过如下命令手动指定gtid：
set gtid_next='1f0eee4c-a66e-11ea-8999-00dbdfe417b8:10';
begin;
commit;
set gtid_next='AUTOMATIC';
故这里产生了另外一个事件，其gtid 为 10,下一条语句产生的GTID会是 11 还是 4 呢？
从这里看成，会先使用空洞，其binlog记录如下。
从这里看出，在后续避免数据顺序性方面，使用GTID并不是一个十全的方法，基于binlog的写入时间更为靠谱。
好了，本文就介绍到这里了，您的点赞与转发是对我持续输出高质量文章最大的鼓励。
欢迎加笔者微信号(dingwpmz)，加群探讨，笔者优质专栏目录：
1、源码分析RocketMQ专栏(40篇+)
2、源码分析Sentinel专栏(12篇+)
3、源码分析Dubbo专栏(28篇+)
4、源码分析Mybatis专栏
5、源码分析Netty专栏(18篇+)
6、源码分析JUC专栏
7、源码分析Elasticjob专栏
8、Elasticsearch专栏（20篇+）
9、源码分析MyCat专栏