完整题目
在大规模知识图谱系统中，如何设计更新机制来保证知识的实时性和一致性？请讨论增量更新、流式处理等相关技术方案。
本文目录
先定义“实时”和“一致”
实时性要写成可测的 SLO，例如某类变更从权威源提交到查询可见的 P95 延迟；一致性则要说明查询是否允许读旧版本、跨实体约束是否必须同时生效，以及删除和权限变化多久内完成传播。不同数据不能共用一条承诺：价格、道路封闭、别名和离线统计的风险不同。
1. 变更事件与顺序
无论入口是 CDC、消息、回调还是批量文件，都先归一成带有 event_id、实体键、操作类型、来源版本、事件时间和内容哈希的变更事件。event_id 用于幂等；来源版本而不是消费者收到消息的时间决定新旧。删除应有 tombstone 或明确的失效版本，不能只从当前索引消失。
Kafka 只保证主题分区内的顺序，因此需要按实体键分区；涉及多个实体的关系变更还要有事务边界或可补偿状态机。重复、晚到和乱序事件要进入版本比较、去重与对账流程，水位线描述事件时间进度，但不能证明再也没有晚到数据。
2. 流处理与状态选择
Flink 可以按实体键维护去重、版本和聚合状态，并把无法自动裁决的数据送到侧输出或隔离队列。不过状态后端没有通用唯一选择：HashMapStateBackend 是默认方案，适合状态能放入 JVM 堆且追求低延迟的场景；EmbeddedRocksDBStateBackend 或 ForSt 等方案可承载更大的状态并支持相应的增量检查点/远端能力，但有序列化、磁盘或网络开销。要按状态规模、恢复时间、尾延迟和运维条件压测。
读取存量图也不是“一律不能查图库”。可以使用图数据库的批量接口、异步 I/O、物化缓存或本地状态，选择取决于一致性窗口、缓存失效和负载。缓存若不是权威源，必须用版本校验和回源避免把旧值重新写回。