直到最近，我还认为生产者、领导人选举和元数据的过程是这样的:
- 生产者发布到一个关闭的领导代理，这将失败。
- 生产者尝试了几次(或零，取决于配置)。
- 最终生产者将"失败"发布该消息。
- 这将触发Producer联系broker获取一个新的元数据块，因此它可以找到新的leader并继续。
然而，我观察到的是生产者阻塞用尽重试和不做任何事情，直到元数据刷新"自动"。刷新将基于在这个属性中配置的时间(来自Apache的Kafka文档):
metadata.max.age。ms:以毫秒为单位的一段时间，即使我们没有看到任何分区领导变化，我们也会强制刷新元数据，以主动发现任何新的代理或分区。
所以基本上，如果生产者碰巧在元数据即将过期的时间附近阻塞，生产将很快恢复。但是，如果生产者在最后一次自动刷新发生几秒钟后阻塞，考虑到该属性的默认值是5分钟，那么生产者将在几乎所有时间内被阻塞。
有什么我错过了或没有正确理解?
谢谢。
我也有过同样的经历。我唯一明白的是你必须小心metadata.max.age.ms的性质。如果你的数据处理是至关重要的，你不想失去你的消息，因为领导选择没有发生，试着保持metadata.max.age.ms property尽可能低。但是这会增加元数据更新的开销。