Flink EOS--整合MySQL验证2PC

​

一、前言

假设当前Flink应用已实现EOS（即 Exactly-Once Semantics）语义，现在需要增加Flink处理数据持久化到MySQL，前提条件不能打破Flink EOS的生态。官方提供的flink-connector-jdbc并没有提供事务和checkpoint的相关操作，自定义sink需要考虑和CheckPoint复杂的配合。参考Flink EOS如何防止外部系统乱入，可自定义实现TwoPhaseCommitSinkFunction类，完成MySQL外部系统组件的完美嵌入。

本次模拟Flink消费Kafka数据并写入MySQL，通过自定义MySQL Sink验证Flink 2PC以及EOS的准确性。相应的系统及组件版本如下，Flink的部署方式为Standalone。

组件/系统	版本
centOS	7.5
Flink	1.12.2
MySQL	5.7
Kafka	2.3.1
Zookeeper	3.4.5
Hadoop	2.6.0

二、验证

思路及猜测结果：

kafka发送：一共发送20条数据，每条数据末尾数字自增，方便观察效果。每条发送间隔为10秒，一共耗时200s。

flink处理：checkpoint时间价格为60s，重启延迟为10s，处理第10条数据的时候模拟发生bug，处理完第19条数据的时候，手动取消job，利用checkpoint恢复job。

猜测1：发生bug时，处理过的数据但未做checkpoint不能持久化到MySQL，只有做了checkpoint的数据才能持久化到MySQL。即checkpioint的提交和MySQL事务的最终提交是保持一致的。

猜测2：job重启会进行事务回滚，重新执行写入事务操作。

猜测3：job失败，利用checkpoint恢复job能保证数据恰好处理一次的精确语义。

验证猜测1：

通过截图日志以及两图对比可知，checkPoint完成后回调了MySQL的commit操作，且尾数134之前的数据全部写入MySQL（即最后一次checkpoint之前的数据全部持久化成功），说明MySQL的事务是和checkpoint保持一致的。

验证猜测2：

通过对比job重启前后的日志对比，发现135-137数据发生了事务回滚，并重新进行的写入操作。

验证猜测3：

job未手动重启之前，可以看到kafka producer实际发送的数据和持久化MySQL的数据是不一致的，接下来就是验证，利用Flink的checkpoint恢复作业最终能达到精确一次消费的语义。

找到最后一次checkpoint的路径，执行以下命令进行job恢复

bin/flink run -s hdfs://lsl001:8020/checkpoint/flink-checkpoint/ca7caa1b21052bb1dbb02d5533b93df4/chk-5 flink_study-1.0-SNAPSHOT.jar --detached

job重启成功，从截图日志可看到，没有持久化成功的数据，重新执行了写入操作，最终通过checkpoint成功提交事务。MySQL查询结果如下图:

三、总结

通过上述的测试流程，我们可以得到如下结论：

1. Flink Job重启或者失败，事务都会回滚，并且都能最终保证数据的精确一次消费。
2. Flink CheckPoin和两阶段提交时密切绑定的。
3. 自定义MySQL sink实现TwoPhaseCommitSinkFunction类可完成MySQL系统友好的融入Flink EOS生态。

案例参考代码: flink_demo