1.一种比较干净但是暴力的做法是Flink一旦检测到分区变化，就执行作业fo. fo后读取最新的分区列表，旧的分区从状态中进行offer重放，新分区执行特定的点位启动策略。它的做法比较干净暴力。
2.第二种就是动态的分区发现（指作业fo，异步线程一直check分区变化，针对removed或者insert的分区单独处理）， 这个在 newKafkaSource 中已经实现了。旧的kafka source实现社区有 FLIP[1] 讨论这个问题。实现侧来看，这种方案相对于第一种复杂一些，需要开发者比较小心的处理状态以及某些极端环境的fo导致的问题[2]。 [1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-288%3A+Enable+Dynamic+Partition+Discovery+by+Default+in+Kafka+Source [2] https://issues.apache.org/jira/browse/FLINK-31006 其实这两种做法不仅仅适用于kafka，对于任意的source或者mq都可以使用。希望对你有所帮助。 Best Regards, Ran Tao casel.chen <casel_c...@126.com> 于2023年4月20日周四 15:43写道： > > 实际工作中会遇到kafka版本升级或者kafka扩容（横向或纵向），数据重平衡等情况，想问一下发生这些情况下对线上运行的flink作业会有什么影响？flink作业能感知topic分区发生变化吗？要如何应对以减少对flink作业消费端的影响？
