CAP 定理与工程中的真实取舍

CAP 定理（Brewer）指出：在存在网络分区时，分布式系统无法同时满足：

• C（Consistency） — 每次读都能读到最新写入，或返回错误（线性一致视角的简化理解）。
• A（Availability） — 每个请求都能得到非错误响应（不要求读到最新）。
• P（Partition tolerance） — 分区发生后系统仍能继续工作（节点间消息可能丢失/延迟）。

真实部署几乎必须接受 P，于是分区发生时要在 C 与 A 间做选择——不是「三选二」的日常开关，而是按业务路径分别设计。

分区时的二选一（概念图）

flowchart TB
  subgraph normal [无分区]
    W[写入成功] --> R[读到最新]
  end
  subgraph partition [发生分区 P]
    CP[选 CP] -->|拒绝部分读写| ERR[返回错误 / 降级]
    AP[选 AP] -->|继续服务| STALE[可能读到旧副本]
  end
  normal --> partition

对照：CP 与 AP 在 ShopFlow 中的例子

PACELC 延伸（了解即可）

无分区时仍要在延迟（L）与一致（C）间权衡：例如跨地域复制常降低一致级别以换更低延迟。设计评审时可问：「正常时要多一致？分区时要多可用？」

强一致、最终一致与因果一致

「一致性」在不同语境含义不同：数据库事务、副本同步、客户端会话。下表是架构讨论中最常用的划分。

序列图：最终一致下的读延迟

sequenceDiagram
  participant App as order-service
  participant M as DB 主
  participant R as DB 从
  App->>M: UPDATE stock=9
  M-->>App: OK
  App->>R: SELECT stock
  R-->>App: stock=10 (复制滞后)
  Note over M,R: 异步复制追上后读到 9

场景决策：接口选哪种一致级别

互动：副本读一致性级别（示意）

BASE 与互联网业务常见策略

BASE 是对 AP 路径的实操总结（与 ACID 相对）：

• Basically Available — 核心路径尽量有响应，非核心可降级。
• Soft state — 中间状态允许存在（处理中、待对账）。
• Eventually consistent — 通过复制、消息、定时任务达到一致。

ACID vs BASE（单服务 vs 跨服务）

代码：Transactional Outbox 预览

「写订单表 + 发 Kafka」无法靠本地事务一起提交。常见做法：Outbox 与业务写入同一事务，再由投递器异步发消息。

@Transactional
public void createOrder(CreateOrder cmd) {
  orderRepository.save(cmd.toOrder());
  outboxRepository.save(OutboxEvent.orderCreated(cmd.orderId()));
  // 同一 DB 事务；消息由 poller 异步投递，消费者须幂等
}

互联网常见组合拳

• 幂等键 — 重复请求返回同一业务结果。
• 对账任务 — 日终比对订单、支付、库存流水。
• 状态机 — 订单 CREATED → PAID，非法跳转拒绝。
• 降级开关 — 分区时关闭非核心功能，保护核心下单路径。

分布式锁、租约与 fencing token 概念

跨节点互斥（定时任务抢主、库存扣减串行化）常用分布式锁。实现须考虑：锁持有者崩溃、时钟漂移、旧锁未释放就获得新锁。

• 租约（Lease） — 锁带 TTL；持有者须周期性续租，否则自动释放。
• Fencing token — 单调递增令牌；下游存储拒绝比当前令牌更旧的写，防止「僵尸持有者」覆写新主。

流程：为何需要 fencing

sequenceDiagram
  participant N1 as 节点1(旧主)
  participant L as 锁服务
  participant DB as 存储
  N1->>L: 曾持有 lock#5
  Note over N1: GC 停顿后「以为」仍持有锁
  participant N2 as 节点2(新主)
  N2->>L: 获得 lock#6
  N2->>DB: write(token=6)
  N1->>DB: write(token=5) 
  Note over DB: 无 fencing 时旧写可能破坏新写

代码对比：锁值是否单调

// 下游无法区分「旧主迟到的写」
String lockVal = UUID.randomUUID().toString();
redis.set("lock:job", lockVal, NX, PX, 30000);

long token = lockService.acquire("inventory-shard-1", Duration.ofSeconds(30));
inventoryRepository.decrement(skuId, qty, token);
// 仓储层: if (token < lastAppliedToken) reject;

Java 生态常见组件：Redis Redisson、ZooKeeper Curator、数据库 SELECT … FOR UPDATE（有单点边界）。能不用锁就不用：优先幂等、分区键串行、CRDT 等业务手段。

读己之写、单调读等客户端语义

即使存储标记为「最终一致」，产品仍常要求会话级体验保证（由网关粘滞、读写路由或版本号实现）：

配置预览：读写分离时的「读主」开关

shopflow:
  datasource:
    read-your-writes: true
    # 创建订单后的 5s 内，该 userId 查询走主库

FAQ

下一章讨论 架构风格：单体、SOA 与微服务，把本章取舍落到架构形态选择。