系列导航：1 | 2 | 3 | 4 | 5 | 6

两个节点各保存 1000 万条记录，直接交换全部身份键和行指纹可以得到精确差异，但通信量和排序成本很高。若双方已经维护稳定分桶和本地指纹状态，可以先交换小摘要，只对不一致区域继续下钻。差异条目很少时，还可以用 IBLT 直接恢复差集。

这些结构优化的是对账和差异定位。源端没有日志、版本或预存摘要时，首次生成全量状态仍需读取 $N$ 条记录。任何摘要结构都无法从未读取的数据中推断变化。

一、对账对象先固定

对账不能直接对任意行对象求 Hash。双方先约定：

datasetId
schemaId
canonicalizationVersion
identityKeyEncoding
rowFingerprintAlgorithm
partitionAlgorithmVersion
snapshotEpoch 或 comparisonBoundary

每条记录映射为集合元素：

$$ x=encode(IdentityKey, RowFingerprint) $$

如果只比较身份键，只能发现新增和删除，无法发现内容更新。把身份和内容指纹共同编码后，同一键内容变化会表现为删除旧元素并新增新元素。结果解码后再按身份键合并成 UPDATE。

对账边界也要一致。节点 A 对应 10:00 的状态，节点 B 已处理到 10:05，摘要不同并不代表数据损坏。双方应冻结一个可比较 Epoch，或记录各分区的日志位置和 Watermark，在共同边界上生成摘要。

二、单个 Hash 无法解释差异

把所有元素排序后计算一个 SHA-256，可以判断“集合大概率相同”，但摘要不一致时无法定位哪条记录有问题。重新传输全量集合会失去摘要的工程价值。

只使用 XOR 也不够。定义：

$$ X(S)=\bigoplus_{x\in S}h(x) $$

XOR 可交换、可结合，相同元素能抵消，适合合并分片。不过它丢失了计数信息，重复元素会相互抵消，多组不同输入也可能得到相同结果。对账摘要可组合多个统计量：