我们有一个使用处理器 API 构建的 Kafka Streams Java 拓扑。
在拓扑中，我们有一个处理器，可以保存到多个状态存储中。
当我们使用 at_least_once 时，我们希望看到状态存储之间的一些不一致 - 例如，传入记录导致写入状态存储 A 和 B，但保存之间的崩溃导致只有存储 A 被写入到状态存储Kafka 更改日志主题。
我们是否保证我们保存的顺序也将是写入状态存储的顺序？例如，如果我们先保存到存储 A，然后再保存到存储 B，我们当然会出现写入两个变更日志都成功的情况，以及只完成写入变更日志 A 的情况 - 但我们也可以结束仅完成写入更改日志 B 的情况？
什么情况会导致重播？当然是崩溃 - 但是重新平衡，新的代理分区领导者，或者当我们收到“偏移提交失败”错误（请求超时）时呢？
前段时间，我们尝试使用exactly_once，这导致了很多错误消息，这对我们来说没有意义。Exactly_once 会为我们提供跨多个状态存储的原子写入吗？
广告 3. 根据有关 Kafka Streams 中的一次性支持的原始设计文档，我认为eaxctly_once您可以跨多个状态存储进行原子写入
当 stream.commit() 被调用时，会依次执行以下步骤：
- 刷新本地状态存储（KTable 缓存）以确保所有更改日志记录都发送到下游。
- 调用 producer.sendOffsetsToTransactions(offsets) 以提交当前记录的消费者在事务中的位置。请注意，尽管线程的使用者可以在多个任务之间共享，因此多个生产者，任务的分配分区始终是独占的，因此只提交此任务分配分区的偏移量是安全的。
- 调用 producer.commitTransaction() 提交当前事务。结果，表示为上述三元组的任务状态是原子提交的。
- 再次调用 producer.beginTransaction() 开始下一个事务。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句