PHP 面试问答

Appearance

[L2] BASE理论：最终一致性的三要素与实现方式 ​

一句话结论 ​

BASE 是对 CAP-AP 系统的工程化表达：允许短暂不一致，但数据最终必须收敛。

体系讲解 ​

1. BASE 是什么

BASE 由 Dan Pritchett（eBay 工程师）在 2008 年提出，是对 ACID 的放宽，也是 AP 系统的工程指导原则：

缩写全称含义
BABasically Available基本可用：允许响应时间略有增加或部分功能降级，但核心服务不中断
SSoft State柔性状态：系统中间态（如"支付中"）允许短暂存在，数据可以不同步
EEventually Consistent最终一致：在没有新写入的情况下，所有节点的数据将在有限时间内收敛到一致

2. BASE vs ACID

维度ACIDBASE
一致性强一致（事务结束即一致）最终一致（允许窗口期不一致）
可用性锁 / 两阶段提交，可用性低无分布式锁，可用性高
适用场景金融账务、库存原子扣减购物车、点赞、用户行为记录
代表系统MySQL InnoDB、PostgreSQLCassandra、DynamoDB、Redis 集群

两者不是非此即彼：系统内不同模块可以混用，核心账务用 ACID，边缘功能用 BASE。

3. 最终一致性的四种实现模式

最终一致性实现模式
├── ① 异步复制（Async Replication）
│     写主库，从库异步同步；读从库可能拿到旧数据
│     代表：MySQL 主从、Redis 主从
├── ② 本地消息表（Outbox Pattern）
│     业务数据与消息在同一本地事务写入，异步发到 MQ
│     代表：电商下单→库存扣减→物流创建
├── ③ 补偿事务（Saga / 对账）
│     各步骤独立执行，失败时触发逆向补偿
│     代表：旅行预订（机票+酒店+租车）
└── ④ 读修复（Read Repair）
      读时检测多副本数据冲突，按版本号/时间戳合并
      代表：Cassandra 读修复，DynamoDB 向量时钟

4. "最终"的时间窗口

最终一致性的"最终"需要被量化为 SLA：

场景可接受窗口
社交点赞数数分钟
电商库存展示数秒
支付状态同步< 5s
账户余额不允许（须强一致）

超出窗口的不一致应触发补偿 / 告警 / 人工介入，而非无限期等待。

5. 基本可用的降级示例

正常状态：推荐列表实时个性化，P99 < 100ms
基本可用：推荐服务过载时，降级为缓存热榜（P99 < 50ms）
不可接受：推荐接口直接返回 5xx，页面空白

考察意图 ​

考察候选人能否将"最终一致性"从概念落地到具体实现模式（Outbox、Saga、读修复等），以及理解"最终"必须有时间窗口约束——开放式的"最终"等于没有承诺；同时考察 BASE 与 ACID 的适用边界，避免"一刀切"地将所有场景套用同一模型。

追问链 ​

  1. 最终一致性如何检测和修复不一致？

    常见手段：①定时对账任务扫描数据差异（如每日清算）；②Cassandra 的 Read Repair——读操作时后台比较副本版本，不一致则同步最新值；③消息幂等消费+补单机制——MQ 消息持久化，消费失败重试，下游以业务 ID 去重防止重复操作。

  2. "柔性状态"中的中间状态如何设计状态机？

    以订单为例：pending → paying → paid → shipped → completed，每个状态转换均有对应事件驱动；中间态（paying）设置超时阈值（如 30 分钟），超时未转换则触发补偿（取消支付、回滚库存）。状态机需保证只能正向或特定逆向跳转，防止跳态。

  3. BASE 系统如何防止无限期不一致（数据永远不收敛）？

    ①幂等消费保证消息被至少处理一次；②最大重试次数 + 死信队列（DLQ）兜底，超出重试进入人工处理；③版本向量或时间戳检测"写写冲突"，选择合并策略（LWW / 业务逻辑合并）；④监控指标告警：不一致数据量超阈值时触发告警。

易错点 ​

  1. 把"最终一致性"理解为"随时可以不一致"：最终一致性有明确的时间窗口承诺（SLA），超出窗口的不一致属于故障，必须有补偿机制；而非"数据最终会一致，不管多久"。

  2. 认为 BASE 系统不需要幂等：最终一致性通常依赖消息重试实现，at-least-once 投递必然带来重复消费，幂等是 BASE 系统的配套必需品，不是可选项。

  3. 对"基本可用"的降级边界不清晰：基本可用要预先定义哪些功能允许降级（推荐、评论）、哪些不可降级（支付、下单），若降级边界模糊，会导致核心功能在故障时也被误降级。

代码示例 ​

php
// 订单状态机：柔性状态管理 + 超时补偿（BASE 中间态设计）
class OrderStateMachine
{
    private const TRANSITIONS = [
        'pending' => ['paying'],
        'paying'  => ['paid', 'cancelled'],
        'paid'    => ['shipped'],
        'shipped' => ['completed'],
    ];

    public function transition(Order $order, string $newStatus): void
    {
        $allowed = self::TRANSITIONS[$order->status] ?? [];
        if (!in_array($newStatus, $allowed, true)) {
            throw new \DomainException(
                "非法状态跳转：{$order->status} → {$newStatus}"
            );
        }
        $order->status     = $newStatus;
        $order->updated_at = new \DateTimeImmutable();
        $order->save();
    }

    /** 超时补偿：paying 状态超过 30 分钟则取消 */
    public function compensateTimeout(Order $order): void
    {
        if ($order->status !== 'paying') {
            return;
        }
        $timeout = new \DateInterval('PT30M');
        if ($order->updated_at->add($timeout) < new \DateTimeImmutable()) {
            $this->transition($order, 'cancelled');
        }
    }
}

基于 Apache License 2.0 开源

PHP 面试问答