对账是金融系统的核心模块，是保障资金安全、数据一致性的最后一道防线。
本文从金融业务视角出发，系统介绍对账的完整体系，包括对账分类、架构设计、核心算法、账务处理和生产实践，帮助你构建企业级对账系统。
对账定义：
对账(Reconciliation)是指将两个或多个数据源的数据进行核对，发现差异并分析原因的过程。
在金融系统中，对账的核心目标：
├─ 资金安全：确保资金流水准确无误
├─ 数据一致：保证各系统间数据一致
├─ 风险控制：及时发现异常交易
└─ 合规要求：满足监管审计要求周五下午 5 点，客服反馈大量用户投诉：明明支付成功了，订单状态却显示"待支付"；优惠券已经核销了，但订单里还显示"未使用"。你打开数据库一看，订单库和支付库的数据对不上——在一个微服务架构的系统中，数据不一致是最让人头疼的问题之一。它不像 OOM 或 CPU 飙升那样有明确的告警，而是悄无声息地累积，直到用户投诉才被发现。本文将系统性梳理数据不一致的排查和修复全流程。
┌──────────────────────────────────────────────────────────────────┐
│ 微服务数据不一致的 5 种典型场景 │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 场景1: 跨服务操作部分成功 │ │
│ │ 订单服务 ──▶ 创建订单(✓) │ │
│ │ 库存服务 ──▶ 扣减库存(✗ 网络超时) │ │
│ │ 优惠券 ──▶ 核销券(✓) │ │
│ │ 结果: 订单创建了，券核销了，但库存没扣 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 场景2: 消息消费部分失败 │ │
│ │ Producer ──▶ 发送消息(✓) ──▶ 事务提交(✓) │ │
│ │ Consumer ──▶ 消费消息 ──▶ 更新DB(✗) ──▶ ACK(✓) │ │
│ │ 结果: 消息被确认消费了，但数据库更新失败 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 场景3: 并发更新顺序不一致 │ │
│ │ 线程A: 读旧值 ──▶ 计算 ──▶ 写入 │ │
│ │ 线程B: 读旧值 ──▶ 计算 ──▶ 写入 │ │
│ │ 结果: 后写的覆盖先写的，但逻辑上应该 A 在前 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 场景4: 缓存与数据库不一致 │ │
│ │ DB ──▶ 更新(✓) ──▶ 删除缓存(✗ 网络故障) │ │
│ │ 结果: 缓存还是旧值，读到脏数据 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 场景5: 补偿事务执行失败 │ │
│ │ TCC: Try(✓) ──▶ Confirm(✓) ──▶ Cancel(✗ 节点宕机) │ │
│ │ 结果: Try 成功但 Cancel 没执行，资源锁定 │ │
│ └─────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘多级缓存如何保证数据一致是提升系统性能的重要手段，它通过数据复用减少了后端服务的压力。
本文介绍了多级缓存如何保证数据一致的原理和实现方式，帮助你构建高性能的缓存系统。
多级缓存系统中的数据一致性是一个复杂的问题，尤其是在分布式环境中。为了保证数据的一致性，可以采用以下几种策略和技术：
写直达（Write-Through）：
写回（Write-Back/Write-Behind）：
缓存失效（Cache Invalidation）：
时间戳或版本控制：
事件驱动的更新：
一致性哈希（Consistent Hashing）：
两阶段提交（Two-Phase Commit, 2PC）：
最终一致性（Eventual Consistency）：
读修复（Read Repair）：