Flink DataStream API 消费binlog kafka实践

Flink提供了方便快捷的source类来消费kafka消息，因此只需要定义对应

复制代码

kafka source，配置kafka地址便可以消费kafka消息
KafkaSource<String> kafkaSource = KafkaSourceFactory.createDefaultSource(parameterTool, topic, groupId);
DataStreamSource<String> kafkaStream = env.fromSource(kafkaSource, WatermarkStrategy.noWatermarks(), "Kafka Source");

这里有几个问题

如何保证消息的顺序性

首先明白一点kafka能保证分区内有序，所以首先生产端需要保证有序，另外如果kafka是多个分区的，建议按照业务键路由到对应的分区，这样同一条业务数据产生的binlog kafka消息在被消费前是有序的。

如何保证flink消费的有序性呢？一种方式是flink的并行度和kafka分区保持一致或者少于kafka分区数；另外一种方式是使用flink的watermark机制生成 Watermark。而笔者的场景kafka分区只有一个，flink并行度有4个。因此对于笔者而言实际上只有一个flink节点消费kafka。

但是为了提高性能（见下），对数据流进行了keyBy，所以这里的关键是keyBy得是你的业务键

复制代码

// 再按 uuid keyBy，做过滤、MySQL 关联，通过侧输出分流
        SingleOutputStreamOperator<Void> keyedStream = afterMaxUmsId
                .keyBy(YourObject::getUuid)
                .process(new FieldDataEnrichAndRouteKeyedProcessFunction(parameterTool))
                .name("enrich and route");

这里需要注意，只有process里的处理逻辑才会保证数据流是按照你的keyBy进行了分组，如果你再对处理后的流，比如这里的keyedStream再次加工而不进行keyBy，是不会保证按照业务键分组的

如何优化性能，提高消费速度

前文提到，kafka分区只有一个，也就是只有一个实例消费kafka消息，这样消费端很慢，实际上也浪费了flink算子的并行度，因此第一步根据业务键进行了keyBy，分组后便能利用到并行的能力了。

如何避免重复消费

通常业务中会短时间内对同一条数据做多次变更，这样会导致多条binlog消息，如果每条都去处理的话，会造成资源消耗，拖慢整体性能。可以采用flink现成的"时间窗口+聚合函数"方案优化，在一个时间窗口内，仅保留binlog唯一id（ums_id_）最大的一条数据，过滤重复无效更新，降低资源消耗

复制代码

// 按 uuid 分组，5s 滚动窗口内用 aggregate 只保留 umsId 最大的那条
        long windowSec = parameterTool.getLong("window.max.umsId.seconds", 5L);
        DataStream<YourObject> afterMaxUmsId = parsedStream
                .keyBy(WorkRecordBasic::getUuid)
                .window(TumblingProcessingTimeWindows.of(Time.seconds(windowSec)))
                .aggregate(new MaxUmsIdAggregateFunction())
                .name("max umsId in window");