归档数据一致性核心在于归档操作必须作为原事务延伸或严格同步的独立事务。方案一嵌入业务事务实现强一致；方案二基于日志异步归档保障最终一致；方案三双写加补偿机制折中解耦；均需结构化校验与时间窗口统一管理。
归档数据一致性核心在于：归档操作本身必须作为原事务的延伸或严格同步的独立事务，不能脱离业务数据变更的原子性与顺序性。简单说，不是“先提交再归档”，而是“归档完成才算事务真正落地”，或至少确保归档结果与源库状态严格可对齐。
方案一：归档嵌入业务事务（强一致性）
在业务主事务中直接执行归档写入（如 INSERT INTO archive_table … SELECT … FROM main_table WHERE …），并和主表更新/删除放在同一事务内。数据库会保证两者全部成功或全部回滚。
- 适用场景：归档量小、延迟敏感、强一致要求高（如金融流水、审计日志）
- 注意点：归档表需与主表同库（或支持跨表分布式事务），避免跨库导致2PC开销；归档逻辑要轻量，否则拖慢主事务响应
- 示例：用户账户扣款成功后，立即把该笔交易快照 INSERT 到 archive_transaction 表，同一 BEGIN…COMMIT 中
方案二：基于事务日志的异步归档（最终一致性）
监听数据库 binlog（MySQL）、WAL（PostgreSQL）或 CDC 日志，解析出 DML 变更，按事务顺序重放至归档库。关键是要保留原始事务边界（XID/LSN）和提交时间戳。
- 保障一致性的要点：按事务粒度消费、不乱序、支持断点续传、归档端实现幂等写入（如 upsert + version/timestamp 去重）
- 推荐工具：Debezium + Kafka + Flink 或自研消费者；避免用定时拉取 select * where updated_at > last_time，易漏数据或重复
- 补充校验：每日跑一致性比对任务（如 checksum 聚合、抽样主键比对），快速发现偏差
方案三：双写+补偿机制（折中可控）
业务代码中显式双写：主库操作 + 归档库操作，但归档写入单独提交，并记录归档任务状态（待处理/成功/失败）到一张 control_table。
- 失败时靠后台补偿任务重试，直到归档成功；控制表需有唯一约束（如 business_id + archive_date）防重复
- 优势是解耦主流程，适合归档逻辑复杂或跨系统（如写入对象存储+ES）
- 风险点：双写中间态暴露（主库已提交、归档未完成），需配合读隔离策略（如查归档数据前先确认状态）
一致性验证不能只靠“看起来一样”
归档后必须做结构化校验，而非仅人工抽查。重点检查：
- 行数一致性：主表 delete 前 count vs 归档表 insert 后 count（需考虑软删、分区策略）
- 关键字段一致性：对相同业务主键，比对金额、状态、时间戳等不可变字段是否完全一致
- 事务完整性：检查归档数据中是否存在孤立事务（只有 insert 没有 delete/update，或跨事务关联断裂）
- 建议将校验脚本纳入发布后自动巡检流程，异常自动告警
不复杂但容易忽略的是归档过程中的时间窗口管理——比如按天归档，必须明确定义“当天”的边界（是业务时间？数据库提交时间？还是日志生成时间？），所有环节统一口径，否则会出现数据错位或重复归档。
