Kafka Streams状态存储get操作无结果但变更日志有对应值

问题可能原因 #

• 处理顺序滞后：收到墓碑记录时，状态存储还没完成对应键值条目的消费同步。变更日志是先写入的，但状态存储的消费流程有延迟，导致store.get(key)查不到已存在于日志中的键。
• 墓碑的即时清理：部分KV存储会在处理墓碑记录时直接删除对应键的条目，而变更日志会保留墓碑标记用于重放或恢复。这时候你查询存储时键已经被清理，但日志里还能看到相关记录。
• 消费位点偏移：状态存储的消费者可能因为重启、重试等原因，消费位点落后于变更日志的写入位点，导致对应键值条目还没被同步到存储中。
• 一致性级别限制：如果状态存储配置为最终一致性，键值写入后需要一定时间完成同步，此时查询可能无法立即获取到结果。

存储与变更日志不同步的常见场景 #

• 消费能力不足：状态存储的消费者因资源瓶颈（CPU、内存不足）或频繁重试，跟不上变更日志的写入速度，导致大量条目堆积未同步。
• 异常恢复遗漏：消费者异常中断后重启，若位点重置或未正确恢复到中断前的位置，会导致部分日志条目未被消费，存储与日志出现差异。
• 逻辑处理差异：变更日志会完整保留所有操作记录（包括墓碑），但状态存储可能会做条目合并（比如覆盖旧值）或直接删除键，导致两边的"可见内容"不一致。
• 分区处理异常：若变更日志采用多分区架构，消费者未按分区顺序处理或出现分区消费失败，会导致部分分区的条目未同步到存储。

正常同步机制 #

• 分区内顺序消费：状态存储的消费者会严格按照变更日志的分区内写入顺序处理条目，确保先同步键值条目，再处理对应的墓碑记录，避免顺序错乱。
• 消费位点持久化：消费者会将每个分区的消费位点持久化存储，重启后可从上次中断的位置继续消费，保证所有日志条目都能被处理。
• 写入触发消费：只有当变更日志的条目写入确认成功后，才会触发状态存储的消费流程，确保每个合法条目都能进入同步环节。
• 墓碑处理逻辑：状态存储处理墓碑时，会先校验对应键是否存在（部分实现有此逻辑），确认后删除键值并更新自身状态；而变更日志会保留墓碑记录，用于后续的系统恢复、重放或数据校验。

内容的提问来源于stack exchange，提问作者Sumit Baurai