面向大规模关系集合的消息分发，一个基础矛盾是：全量快照容易读取，却会迅速过时；实时查询最新关系最准确，却可能把数据库拖入发送热路径。
三种选择
- 每次生成全量快照：读简单，但生成成本高、时效性差；
- 发送时实时查库：数据新，但放大数据库压力；
- 全量快照叠加增量事件：复杂度更高，却能兼顾读取和新鲜度。
第三种方案的关键不是“多加一个缓存”，而是定义清晰的版本边界：快照对应哪个时间点，增量从哪个序列号开始，重复事件怎样幂等合并。
可恢复的读取模型
周期快照 + 有序增量日志 → 当前关系视图 → 分发任务
消费者记录已应用的增量位点；发生缺口时回退到最近快照重放，而不是修补一个不可解释的中间状态。
工程取舍
实时分发不必追求瞬时强一致。更合理的目标是明确可接受的延迟窗口，并保证系统在重启、重复投递和乱序到达后最终收敛。
当集合规模很大时，“如何恢复”比正常情况下快几毫秒更重要。