[[376033]]

作者個人研發的在高并發場景下，提供的簡單、穩定、可擴展的延遲消息隊列框架，具有精準的定時任務和延遲隊列處理功能。自開源半年多以來，已成功為十幾家中小型企業提供了精準定時調度方案，經受住了生產環境的考驗。為使更多童鞋受益，現給出開源框架地址：https://github.com/sunshinelyz/mykit-delay

寫在前面

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及以上版本。后續會以插件的形式支持更多的異構數據源。例如，后續會增加：SQL Server、Postgre SQL、Redis、ES、Hadoop、HBase、MongoDB、TiDB等數據源。

mykit-data的開源地址如下：

GitHub：https://github.com/sunshinelyz/mykit-data

Gitee：https://gitee.com/binghe001/mykit-data

本文轉載自微信公眾號「 冰河技術」，可以通過以下二維碼關注。轉載本文請聯系 冰河技術公眾號。