我有一个使用处理器api的拓扑，它更新状态存储，配置为复制因子3，acks=ALL
Topologies:
Sub-topology: 0
Source: products-source (topics: [products])
--> products-processor
Processor: products-processor (stores: [products-store])
--> enriched-products-sink
<-- products-source
Sink: enriched-products-sink (topic: enriched.products)
<-- products-processor
我的监控显示，源主题(<100条记录(的滞后性很小，但支持存储的变更日志主题的滞后性很大，达到数百万条记录的数量级。
我正试图找出这个变更日志主题滞后的根本原因，因为我没有在这个处理器中发出任何外部请求。有对rocksdb状态存储的调用，但这些数据存储都是本地的，检索速度应该很快。
我的问题是，这个变更日志主题的使用者到底是什么？
变更日志主题的使用者是恢复使用者。恢复消费者是构建在Kafka Streams中的Kafka消费者。与从源主题读取记录的主要使用者不同，还原使用者负责在本地状态不存在或过期的情况下从变更日志主题还原本地状态存储。基本上，它确保本地状态存储在故障后恢复。恢复使用者的第二个目的是使备用任务保持最新状态。
Kafka Streams客户端中的每个流线程都有一个恢复使用者。恢复使用者不是使用者组的成员，Kafka Streams手动为恢复使用者分配变更日志主题。恢复使用者的偏移不是在使用者偏移主题__consumer_offsets中作为主使用者的偏移来管理的，而是在Kafka Streams客户端的状态存储目录中的文件中管理的。