可视化 MySQL binlog 监听方案

前言

为什么需要可视化的 MySQL binlog 监听方案？

当公司刚起步的时候，研发少、资源有限，但我们需要监听 binlog 日志做业务处理，最快速的方案是引入开源的 MySQL binlog 监听方案，比如(canal)。

随着公司的扩展，团队逐渐增多，每个团队都有监听 binlog 的需求。这个时候每个团队都使用 canal 去监听binlog 就显得太繁琐。不仅是难以维护，更重要的是增加团队成员的理解成本。

所以，集中化 MySQL binlog 监听平台，就几乎成了团队扩展后的必经之路了。

Binlog 二进制日志

MySQL的二进制日志（binlog）是一个重要的功能，用于记录对数据库执行的所有更改操作。它在数据恢复、复制和审计等方面发挥着关键作用。以下是关于MySQL二进制日志的详细介绍：

1. 二进制日志的用途

数据恢复：在发生数据丢失或损坏时，可以使用二进制日志来恢复数据。通过重放日志中的事件，可以将数据库恢复到某个特定的时间点。
复制（Replication） ：MySQL复制依赖于二进制日志。主服务器将其更改记录到二进制日志中，从服务器读取这些日志并重放，以保持与主服务器的数据同步。
审计和分析：二进制日志可以用于审计数据库操作，帮助分析数据更改的历史记录。

2. 二进制日志的组成

事件（Event） ：二进制日志由一系列事件组成，每个事件代表一个对数据库的更改操作，如INSERT、UPDATE、DELETE等。
日志文件：二进制日志

可视化监听方案

一个平台化的解决方案，使业务方能够通过简单的配置来监听 MySQL 的 binlog ，并将其输出到 Kafka，同时提供一个可视化界面来展示和管理这些数据。

对业务方：通过界面化的方式，配置待监听的数据源 + 配置待输出的目标源（比如kafka）即可拥有监听 binlog 的能力。
对研发：学习成本低，扩展性强、效率高
对平台：统一管理，产品功能齐全、监控方案更容易展开实现

canal 监听方案

canal 官方流程图：

canal的工作原理是把自己伪装成 MySQL slave ，模拟MySQL slave的交互协议向 MySQL Mater发送 dump协议

MySQL mater 收到 canal 发送过来的 dump 请求，开始推送 binary log 给 canal，然后 canal 解析 binary log，再发送到存储目标输出源，比如 MySQL，Kafka，ES 等。

这里本质上，canal 利用 MySQL 提供的 slave dump 通信协议，模拟成 slave 从节点，从而获取 binlog 日志。

可视化平台方案

平台化具有哪些能力：

监听 binlog（核心能力）
可视化配置界面
实时监控
异常告警
高并发/高扩展能力
离线统计与备份
...

有了平台化的管理能力，扩展性将得到大大提升。

除了 canal 之外是否可以自己实现 binlog 监听组件？

当然可以，在当下的较大体量的公司中，一般都有自己的监听 binlog 组件，便于迭代维护。我们可以借鉴开源的 canal 实现自己的 binlog 监听组件，监听流程思路都是大差不差。

可视化配置界面关注哪些核心能力？

输入源 + 输出源配置
监听表上线、线下能力
基本页面搜索、列表展示能力

输出源配置，以输出到 kafka 为例：

为避免管理困难+输出topic泛滥，我们可以一个数据库使用同一个kafka topic 进行输出
不同的业务方都可以监听这个 topic，不过在使用时过滤出需要的监听表即可

这种方案能支持绝大部分场景，很多大厂都在采用这种方案。

当然，如果你存在量级非常的大表，也可以采用单独的输出 topic 进行输出。

高并发/高扩展层需要关注什么？

监听 binlog 通常意味着数据量大，如果只有一个节点可能出现单节点故障或者效率低下、大批量延迟等问题。

可以考虑使用多个 woker 节点同时处理并解析 binlog 数据，也即是分布式集群了。

有了分布式集群，就需要考虑分布式协调，这里常用的如 zk 来负责管理分布式节点，负载均衡各节点压力。

甚至可以继续优化：

负载均衡策略、分队列多机房部署、启动加载配置优化和kafka调优、失败重试及阻塞机制调整等
多个kafka输出、Mysql异常主备切换等

方案架构

这里输入源以 MySQL，输出源以 Kafka 进行考虑。

数据源配置模块：提供一个界面让用户配置MySQL数据源。
Binlog 监听模块：负责从MySQL读取binlog并解析。
Kafka 输出模块：将解析后的数据发送到Kafka。
可视化管理界面：用于展示和管理binlog数据流。

详细设计

1. 数据源配置模块

用户界面：提供一个简单的 Web 界面，用户可以在此输入 MySQL 数据库的连接信息（如主机、端口、用户名、密码）以及需要监听的数据库和表。
配置存储：将用户的配置存储在一个配置数据库中，确保配置的安全性和可用性。

2. Binlog 监听模块

工具选择：使用 Canal 或自研的组件来监听 MySQL 的 binlog。这些工具可以无缝地将 binlog 事件转换为 JSON 格式的数据。
动态配置：监听模块需要能够动态加载用户配置的 MySQL 数据源，并启动相应的 binlog 监听任务。
故障处理：实现自动重连和故障恢复机制，确保监听的稳定性。

如果是自研 binlog 监听组件，需要考虑可靠性和并发性等基本要求。

3. Kafka 输出模块

数据转换：将 binlog 事件转换为 Kafka 消息格式，确保消息的结构化和一致性。
消息发送：将转换后的消息发送到用户指定的 Kafka topic 中，支持分区和副本配置以提高可靠性。

4. 可视化管理界面

前端框架：使用 React 或 Vue.js 构建用户界面。
功能设计：
- 数据源管理：展示所有配置的数据源，支持增删改查操作。
- 实时监控：展示实时的 binlog 事件流，支持过滤和搜索。
- Kafka 状态：展示 Kafka 的消息发送状态和统计信息。
- 日志和告警：提供系统日志查看和异常告警功能。