抱歉，想使用Flink Kafka universal connector连接Kafka 2.3.0请先等等！

有没有人注意到Kafka 昨天发了2.3.0？是的，我也是刷Twitter看到的，然后我就想要不把社区的Kafka universal connector的依赖升上去吧。反正这个connector从引入时跟踪的2.0.0以及最新的2.2.0都是我升级的。

原本，以为升级会一如既往得顺利。不过，最终发现还是想当然了。不怎么关注Flink kafka connector内部实现的童鞋可能不清楚，自Kafka支持producer端事务以来，Flink就在0.11版本的connector提供了对该特性的支持，这样它就可以在sink端针对Kafka提供Exactly-Once的语义。

但具体的实现，其实很“ugly”，而这个话题说来话长。Flink的2PC SinkFunction，里有个 initializeState 方法，最终会调用内部的 recoverAndCommitInternal 而它又间接调用的 recoverAndCommit 方法是需要最终的实现者override的。对应到Kafka producer的实现，就是 FlinkKafkaInternalProducer#resumeTransaction 方法。在恢复事务之前，它需要先拿到 KafkaProducer#transactionManager 这个实例字段，然后再拿这个实例字段内部的 nextSequence 字段（类型为 Map<TopicPartition,Integer> ），并调用 clear() 方法清空它后才能回置相关字段并恢复事务。是的，所有的这一切都是通过反射机制来实现的，包括获取 nextSequence 这个字段，因为这些操作Kafka produer没有公开，而也正是因为这个原因，Kafka也不会承诺它维持内部实现不变。

其实，在实现universal connector的时候，已经碰到过这个问题了，在Kafka client 2.0之前，这个字段名叫 sequenceNumbers ，后来才改叫 nextSequence 。这次升级问题同样出在这个字段上，升级PR对应的Travis抛出如下异常：

这次不是变量命名的问题，而是 TransactionManager 内部实现进行了较大的重构！相应的issue是：KAFKA-7736，它引入了两个内部类： TopicPartitionBookkeeper 以及 TopicPartitionEntry ，并把 nextSequence 放到了 TopicPartitionEntry 中去了。这还仅仅只是表面观察到的，还没来得及细看具体是否存在其他问题。

所以等不及要上Kafka 2.3.0的童鞋请先等等，更多进展请关注FLINK-12976！所以，搞个Flink容易么，还得跑到Kafka源码里去了解细节。所以你还不加个星球鼓励一下？

有问必答，问倒算我输！