一、数据一致性概述
大家好，我是老张。在交易系统这个行当摸爬滚打了十几年，今天咱们来聊聊数据一致性。这玩意儿，说白了就是分布式系统的命根子。
我记得刚入行那会儿，带我的师傅说过一句话，到现在我都记得清清楚楚：「做交易系统，数据错了，那就是真金白银的损失。」嗯，这话一点不夸张。
什么是数据一致性
数据一致性，简单理解就是：多个数据副本之间，或者多个系统之间，数据要保持「长得一样」。
举个例子。你在支付宝转了100块钱给朋友。你的账户扣了100，朋友的账户加了100。这两个操作必须同时成功，或者同时失败。不能出现你扣了钱，朋友没收到的情况。这就是一致性。
在分布式系统里，数据一致性分几个层次：
- 强一致性：写完数据后，任何读操作都能立刻读到最新值。就像银行转账，实时到账。
- 弱一致性：写完数据后，不保证立刻读到最新值。比如你发了个朋友圈，朋友可能过几分钟才看到。
- 最终一致性：是弱一致性的一种特例。保证「最终」数据会一致，但中间可能有延迟。DNS系统就是典型例子。
我个人习惯：在设计交易系统时，核心链路必须用强一致性。非核心链路，比如日志、报表，可以用最终一致性。这个取舍，后面会细说。
为什么交易系统需要强一致性
这个问题，我直接说答案：因为钱不能错。
你想想看，一个交易系统，每天处理几亿笔交易。如果数据不一致，会出现什么后果？
- 用户账户余额对不上
- 订单状态混乱
- 清算对账通不过
- 监管罚款找上门
我在项目中遇到过最惨的一次。某个支付系统因为缓存和数据库不一致，导致用户重复扣款。虽然最后把钱退回去了，但用户投诉、公关危机、监管约谈，整整折腾了一个月。那滋味，真不好受。
所以，交易系统对数据一致性的要求，是写在基因里的。你可以接受慢一点，但不能接受错一点。
CAP理论在交易场景下的取舍
说到分布式系统，CAP理论是绕不开的。C（一致性）、A（可用性）、P（分区容错性），三者只能取其二。
这个理论，我刚开始学的时候也觉得挺玄乎。后来做项目做多了，才真正理解它的分量。
| 组合 | 含义 | 交易场景适用性 |
|---|---|---|
| CP（一致性+分区容错） | 牺牲可用性，保证数据一致 | 核心交易链路，如订单、支付 |
| AP（可用性+分区容错） | 牺牲一致性，保证服务可用 | 非核心场景，如行情推送、用户通知 |
| CA（一致性+可用性） | 牺牲分区容错，实际很少用 | 单机系统，分布式场景基本不考虑 |
在交易系统里，我们通常怎么做取舍？
- 核心交易链路：选CP。宁可暂时不可用，也不能数据出错。比如下单、支付、清算。
- 非核心链路：选AP。比如用户查询历史订单，稍微延迟几秒没问题。
- 混合策略：这是实际项目中最常见的。核心链路强一致，非核心链路最终一致。
避坑指南：我曾经犯过一个错误，把整个系统都设计成强一致。结果呢？高峰期系统直接雪崩。后来才明白，一刀切的方案，往往是最差的方案。
BASE理论的实际应用
BASE理论，说白了就是CAP理论的「妥协版」。BA（基本可用）、S（软状态）、E（最终一致性）。
这个理论在交易系统里，应用非常广泛。我给大家拆解一下：
基本可用（Basically Available）
系统允许出现部分功能降级，但核心功能必须可用。比如双十一大促，非核心功能可以降级，但支付功能必须扛住。
软状态（Soft State）
允许系统存在中间状态。比如订单状态从「待支付」到「已支付」，中间可能有个「支付中」的状态。这个状态是临时的，但允许存在。
最终一致性（Eventually Consistent）
经过一段时间后，所有数据最终会达成一致。比如跨行转账，A银行扣款后，B银行可能延迟几秒才到账。但最终，钱一定会到。
注意：最终一致性不是「最终可能一致」，而是「最终一定一致」。这个「一定」两个字，需要靠技术手段来保证。比如重试机制、补偿事务、对账系统。
在实际项目中，BASE理论怎么落地？我举个例子：
// 伪代码：订单创建流程
1. 创建订单（状态：待支付）
2. 调用支付服务（状态：支付中）
3. 支付成功回调（状态：已支付）
4. 异步通知库存系统（最终一致）
5. 异步通知物流系统（最终一致）你看，核心的订单状态是强一致的。但库存和物流的更新，用的是最终一致性。这就是BASE理论在交易系统里的典型应用。
知识体系总览
说了这么多，我画了一张图，把这一章的核心逻辑串起来。你一看就明白了：
这张图把这一章的核心逻辑都串起来了。从数据一致性的定义出发，到CAP理论的取舍，再到BASE理论的落地。你仔细看看，应该能有个整体把握。
好了，这一章就聊到这儿。数据一致性是个大话题，后面我们会一步步深入。记住一句话：交易系统里，一致性不是选择题，而是必答题。