在尝试实现恰好一次语义时，我在官方 Kafka 文档中发现了这个：
一次交付需要与目的地合作 存储系统，但 Kafka 提供了偏移量，这使得实现 这直截了当。
这是否意味着我可以使用(主题、部分、偏移量)元组作为唯一的主标识符来实现重复数据删除？ 一个示例实现是使用 RDBMS 和此元组作为大型处理事务中插入操作的主键，如果由于已经存在的主键而无法再插入，则事务将失败。
我认为这个问题等同于：
- 生成者在检测到可能的故障后重试发送消息时是否对消息使用相同的偏移量，或者每次重试尝试都会获得自己的偏移量？
如果在重试时重复使用偏移量，使用者显然会看到具有相同偏移量的多条消息。 其他问题，可能以某种方式相关：
- 单个或多个生产者生产同一主题，一个消费者看到的偏移量序列中是否存在"差距"？
另一种可能性是偏移量是由例如消息到达完成工作的领导者确定的，或者最近由消息到达完成工作的领导者确定(这意味着 - 如果不听生产者建议的偏移量之类的东西 - 可能没有间隙/偏移跳转，但重复消息也有不同的偏移量，我将不得不在应用程序级别的应用程序消息中使用我自己的唯一标识符)。
回答我自己的问题：
偏移量仅由服务器生成(更准确地说：由相应分区的领导者生成)，而不是由生产客户端生成。然后在生产响应中将其发送回生产者。所以：
- 生产者在重试时是否对消息使用相同的偏移量 在检测到可能的故障或每次重试尝试后发送它 获得自己的偏移量？
不(见下面的更新！生产者不确定偏移量，两个相同/重复的应用程序消息可以具有不同的偏移量。因此，偏移量不能用于标识用于生产者重复数据删除的消息，并且必须在应用程序消息中定义自定义 UID。(来源)
- 单个或多个生产者生产同一主题，一个消费者看到的偏移量序列中是否存在"差距"？
由于每个分区只有一个领导者来维护当前偏移量，并且(使用默认配置)此领导仅在发生故障时传输到活动的同步副本，因此我假设在为分区选择新主节点时始终正确传达最新使用的偏移量，因此最初不应有任何偏移间隙或跳转。但是，由于日志压缩功能，在某些情况下(假设启用了日志压缩)，在压缩启动后再次使用已提交的分区消息时，偏移流中确实可能存在间隙。(来源)
更新 (Kafka>= 0.11.0)
从 Kafka 版本 0.11.0 开始，生产者现在还会发送一个序列号及其请求，然后领导者使用该序列号通过此编号和生产者的 ID 删除重复的请求。因此，对于 0.11.0，生成方实现恰好一次语义的先决条件由 Kafka 本身给出，并且无需在应用程序的消息中发送另一个唯一的 ID 或序列号。 因此，问题1的答案现在也可能是肯定的，不知何故。 但是，请注意，只有消费者永远不会失败，语义才有可能。一旦消费者失败，仍然需要注意消费者端的重复消息处理。