写在后面
MySQL是互联网行业应用的最多的关系型数据库之一，而且MySQL又是开源的，对于MySQL的深入研究，可能加深咱们对于数据库原理的了解。自从开源了mykit-data之后，不少小伙伴试用后，反馈mykit-data无奈正确的解析MySQL8的binlog。于是我测试了下，mykit-data在解析MySQL5.x的binlog时，没有啥问题，可能正确的解析出后果数据。然而，在解析MySQL8.x的binlog时，总是与binlog日志位数相差12位而导致解析失败。
文章已收录到：
https://github.com/sunshinelyz/technology-binghe
https://gitee.com/binghe001/technology-binghe
问题修复
明天太晚了，我还在钻研MySQL 8.0.20的源码，问题的修复过程后续再写一篇具体的文章来与小伙伴们分享下。这里，我就间接说我是如何解决这个问题的。
MySQL5.x binlog的解析后果与MySQL8.x binlog的解析后果总是存在位数偏差，框架本来的代码间接解析MySQL 5.x是没啥问题的，在解析MySQL 8.x的时候呈现位数谬误。
期间，我简直翻阅了MySQL的所有官网文档，把mykit-data中对于解析binlog日志的性能从新写了一遍，解析MySQL5.x没问题，解析MySQL8.x还是错位。
到底哪里出了问题呢？就在对于问题的解决束手无策的时候，忽然，想到一个思路：解决MySQL8.x binlog的时候不是总错位吗？那我就把多余位数的binlog数据读取进去，间接疏忽掉，使后续binlog的解析操作对齐不就行了吗？
连忙尝试一下，于是我在mykit-data框架的源码中，增加了如下代码。
下面代码是对解析MySQL binlog位数的校验和读取的封装，当读取的binlog位数未达到读取的限度位数时，始终读取binlog的数据，直到读取的binlog位数达到读取的限度位数地位。具体外部的逻辑，小伙伴们能够浏览mykit-data的源码。
加上这个逻辑后，进行测试验证，解析MySQL 8.x数据库的binlog居然胜利了！！困扰我几天的问题就这么在不经意间解决了！！
从解决这个问题的后果来看，MySQL8.x的binlog在实质上比MySQL5.x的binlog位数要长，两头会拼接用来分隔不同事件位的标识，咱们在解析MySQL8.x的binlog日志时，可间接疏忽掉这些分隔不同事件位的标识，目标就是让binlog的解析位对齐，从而可能正确的解析出下一个事件。而这样解决，也不会影响解析后果。
很多时候就是这样，当你苦于解决某个问题，迟迟找不到解决方案而束手无策时，在某个不经意的霎时，就会无心中解决这个辣手的问题，但前提是你须要深刻理解它的原理并尝试各种形式和办法来解决它！
对于mykit-data
mykit-data是一款齐全开源的数据异构中间件，反对插件化、可视化的数据异构框架，反对MySQL到MySQL、MySQL到Oracle、Oracle到MySQL、Oracle到Oracle的全量、实时/定时增量数据同步。齐全的插件化、可视化操作。通过日志最大限度的防止同步过程中的数据失落。反对失败重试，人工干预，反对查看同步的数据和具体的日志信息。
目前反对MySQL5.x、MySQL8.x，Oracle 11g及以上版本。后续会以插件的模式反对更多的异构数据源。
mykit-data的开源地址如下：
GitHub：https://github.com/sunshinelyz/mykit-data
Gitee：https://gitee.com/binghe001/mykit-data
最初，小伙伴们为这款开源我的项目点个Star呀！！
好了，明天就到这儿吧，我是冰河，大家有啥问题能够在下方留言，咱们下期见~~