请教一下，为什么Flink CDC2.0还是会拿全局锁？

Flink CDC 2.0 在某些场景下仍然会使用全局锁（Global Lock），这主要与 MySQL 数据库的 Binlog 模式和 Flink CDC 的工作原理有关。以下是详细的原因分析及解决方案：

1. 全局锁的来源

在 Flink CDC 中，当使用 MySQL 作为数据源时，默认情况下会在全量阶段（Snapshot 阶段）对表加锁以确保数据一致性。这种锁通常表现为 FLUSH TABLES WITH READ LOCK（FTWRL），即全局读锁。

• 原因：
  • Binlog 格式限制：如果 MySQL 的 Binlog 格式为 STATEMENT 或 MIXED，为了保证全量数据和增量数据的一致性，Flink CDC 需要在全量阶段记录 Binlog 的位点，并在此期间阻止表结构变更或数据写入。
  • 数据一致性需求：在 Snapshot 阶段，Flink CDC 需要确保从全量切换到增量时不会丢失任何数据变更。因此，它通过加锁来避免在全量读取过程中发生数据更新。

2. 如何避免全局锁

为了避免全局锁对数据库性能的影响，可以采取以下优化措施：

2.1 使用 ROW 格式的 Binlog

• 推荐配置：将 MySQL 的 Binlog 格式设置为 ROW 模式。
• 作用：在 ROW 模式下，Flink CDC 可以通过读取 Binlog 中的行级变更信息，而无需依赖全局锁来保证一致性。
• 配置方法：

  SET GLOBAL binlog_format = 'ROW';
  

2.2 跳过 Snapshot 阶段

• 如果不需要全量数据同步，可以通过配置跳过 Snapshot 阶段，直接从 Binlog 开始读取增量数据。
• 配置参数：

  scan.startup.mode=latest-offset
  

  • 说明：此配置表示从最新的 Binlog 位点开始消费，完全跳过全量数据读取阶段。

2.3 使用增量快照算法

• 特性支持：Flink CDC 2.0 引入了增量快照算法（Incremental Snapshot Algorithm），可以在全量阶段并发读取数据，而无需加全局锁。
• 作用：通过分片的方式读取全量数据，并结合 Binlog 实现无锁的数据同步。
• 启用方式：默认情况下，增量快照算法是开启的，无需额外配置。

2.4 设置合理的 server-id

• 重要提醒：每个 Flink CDC 作业需要配置唯一的 server-id，以避免多个作业之间的冲突。
• 配置示例：

  server-id=5404-5412
  

  • 说明：server-id 的范围必须大于等于作业的并发数。

3. 数据库压力优化建议

即使避免了全局锁，Flink CDC 仍可能对数据库造成一定压力。以下是一些进一步的优化建议：

3.1 合并多个 CDC 作业

• 问题背景：多个 CDC 作业同时运行可能导致数据库连接数过多，增加数据库压力。
• 解决方案：将多个 CTAS/CDAS 作业合并为一个作业运行，并为每个 MySQL CDC 源表配置相同的 server-id，实现数据源复用。

3.2 使用 Kafka 解耦

• 方案描述：将 MySQL 的变更数据先同步到 Kafka 消息队列中，再通过消费 Kafka 数据进行解耦。
• 优势：减少对 MySQL 数据库的直接访问频率，降低数据库压力。

3.3 开启 Source 复用功能

• 功能描述：Flink CDC 支持 Source 复用功能，可以合并同一作业中配置项相同的 MySQL CDC 源表，从而减轻 MySQL 服务器的连接和监听压力。

4. 总结与注意事项

• 关键点：Flink CDC 2.0 是否使用全局锁，取决于 MySQL 的 Binlog 格式和配置的启动模式。推荐使用 ROW 格式的 Binlog 和增量快照算法来避免全局锁。
• 重要提醒：在生产环境中，务必根据业务需求合理配置 scan.startup.mode 和 server-id 参数，以确保数据一致性和系统稳定性。

如果您仍有疑问或需要更详细的配置指导，请随时告知！