Flink大声说，丢数据这个锅，我们不背！

 

一。问题现象

笔者所在公司基于kakka-flink-es开发了一套日志中心，以方便业务部分通过日志排查业务问题（日志包括全链路日志，业务日志等）。近期业务部门反馈，日志中心在使用过程中出现了数据丢失的情况，由此引发了大家的的疑惑，Flink不是可以确保END-TO-END 的 EXACTLY-ONCE 语义吗？怎么会丢数据？一口大锅扔给了Flink。

二。数据链路背景

各个微服务使用了 log4j2 的 kafkaAppender，并用AsyncAppender 引用了KafkaAppender, 然后以 Async 方式异步地把日志写入到 Kafka topic中，然后 flink 流处理程序实时消费 kafka 中的日志数据并写入到下游的 elasticsearch中，供业务查询日志使用。在使用过程中发现，es中查询得到日志，相对于微服务的原始日志，有数据丢失的现象。之所以得出改结论，是因为微服务通过 log4j 的 rollingFileAppender 也会把日志落在本地一份，通过对比本地日志和 kafka 中的日志，发现有时数据有丢失。各组件目前使用的版本如下：log4j2.9.1, kafka 2.11-2.2.0，flink 1.11，es 6.3.1。

 

三。问题原因分析

由于业务反馈的日志丢失，是通过对比微服务的原始日志与落在es中的最终日志得出的结论，从数据链路上来讲，问题可能出在微服务通过log4j向kafka写日志，kafka自身存储日志，flink消费kafka日志并写入es，以及es自身存储日志，这些数据链路上的各个环节。则我们也因该顺着数据链路，端到端低分析，哪个环节可能出了问题。

首先 Kafka 和 es 自身都可以通过多副本机制提供持久化的存储与容错，在没有出现硬件多节点故障的情况下，是不会出现丢失数据的问题的。在我们的场景中，kafka topic 创建时都指定了多副本，（当然也可以通过集群级别参数default.replication.factor配置默认值），es也是配置了
replica shard，所以存储层面不存在问题。

然后来看下 flink 消费 kafka 数据的逻辑。

Flink提供了一个kafka consumer的实现，即org.apache.flink.streaming.connectors.kafka.FlinkKafkaConsumer, 该类整合了flink的 checkpoint机制, 通过  checkpoint 机制，flink 提供了作业失败时的恢复能力，应用可以通过配置 checkpoint_interval 来定期触发 Ch