Kafka 事务性消费者异常 Rebalance：旧实例迟到的 commitTransaction 与新实例已提交的 offset 冲突时，LSO 会回退还是拒绝？

【背景】 在 Kafka 的事务性消费者场景中，当旧实例因网络波动或其他原因导致 commitTransaction 延迟，而新实例已经提交了新的 offset，这种情况下，LSO（Log Start Offset）如何处理？是回退到旧的 offset 还是拒绝新实例的 offset？

【常见分歧】

1. 回退方案：认为 LSO 应该回退到旧的 offset，以保证数据一致性，避免数据丢失。
2. 拒绝方案：认为 LSO 应该拒绝新实例的 offset，以确保消费者不会处理重复数据，但可能导致数据丢失。

【我的倾向】 我认为 LSO 的处理逻辑应基于 Kafka 的一致性保障机制和业务场景的权衡。在大多数情况下，回退到旧的 offset 是更安全的选择，因为它能够避免数据丢失，但这也可能引入一定的数据延迟。然而，在某些高吞吐量的场景下，拒绝新 offset 可以提升系统的整体性能，但需要确保业务能容忍数据丢失的风险。

【想听大家的建议】 在实际的业务场景中，你们是如何处理这种 LSO 冲突的情况？是选择回退还是拒绝？在什么场景下你会更倾向于哪种做法？