关于Flink基于MySQL/Redis Sink的两种语义性能基准的问询

问题1：两种语义下MySQL/Redis作为Sink的详细性能基准测试结果 #

• 目前没有官方或社区统一发布的标准化基准数据，因为性能受集群规模、Flink并行度、Kafka分区数、数据库配置、部署架构等大量变量影响，无法给出通用数值。
• 从实际用户测试和社区分享的案例来看：
  • At-least-once语义下：Redis Sink的QPS通常可达数万至十几万（依赖Redis部署模式）；MySQL Sink受磁盘IO和单事务开销限制，QPS大概在数千到一万区间。
  • Exactly-Once语义下：Redis若通过事务或Lua脚本实现幂等，性能下降约10%-30%；MySQL结合TwoPhaseCommitSink的性能下降幅度更大，但具体数值需结合实际配置判断。

问题2：MySQL Sink结合TwoPhaseCommitSink实现Exactly-Once的性能变化 #

• 性能确实会有明显下降，但通过优化可控制在可接受范围，并非必然“大幅”下滑。
• 性能下降的核心原因：TwoPhaseCommitSink的两阶段提交流程（prepare预提交+commit正式提交）增加了额外的网络交互和MySQL磁盘刷写开销；同时Flink为保证语义一致性会严格对齐Checkpoint，限制了Task的处理速度。
• 可通过以下方式缓解性能损耗：
  • 调大Checkpoint间隔，减少事务提交频率
  • 优化MySQL配置，比如调整innodb_flush_log_at_trx_commit参数降低刷写频率
  • 增大Flink并行度，匹配Kafka分区数和MySQL连接池大小
  • 启用JDBC批量写入，减少单条数据提交的开销

内容的提问来源于stack exchange，提问作者sclee1