引言

BASE 是 Basically Available（基本可用）、Soft State（软状态）和 Eventually Consistent（最终一致性）三者的英文缩写，它是 CAP 定理在互联网分布式场景下的落地延伸理论，专门适配 CAP 中 A + P 架构体系，核心思路是主动舍弃强一致性，以此换取系统更高的服务可用性与集群分区容错能力。

数据一致性模型

分布式系统里主流分为三类数据一致性级别，也是理解 BASE 理论的前置基础。

• 强一致性：完成数据更新操作后，后续所有客户端、进程、线程发起的访问请求，都能立刻获取到最新已更新的数据值，数据全局实时统一。

• 弱一致性：数据写入完成后，系统不保证客户端马上读取到最新数据，也无法确定具体多久之后能读到新数据，仅做松散约束。

• 最终一致性：属于弱一致性里最常用的子集。在没有新数据写入更新的前提下，系统会在既定时间内完成数据同步，最终让所有节点数据保持一致。

BASE 三要素

基本可用

• 含义：系统遭遇节点故障、流量洪峰、网络波动等问题时，允许舍弃一部分非核心服务能力，但保障核心业务流程正常对外提供服务，不会整体彻底瘫痪。

• 实现方式

  • 降级策略：系统负载超标或部分节点异常时，关停次要功能缩减资源消耗

  • 限流管控：限制单位时间内并发请求数量，防止服务被海量请求压垮

  • 服务熔断：依赖的第三方服务出现异常时快速终止调用，阻断故障链式扩散，避免雪崩问题

• 典型场景

  • 电商大促活动期间，临时关闭商品闲聊评价、历史浏览记录等非核心功能

  • 微服务架构中接入 Sentinel 等组件实现熔断防护

软状态

• 含义：允许分布式集群内的数据存在临时中间状态，短时间内不同节点数据出现不一致属于正常现象，无需时刻保持全局数据统一。

• 与强一致性区别

  • 强一致性：任意时刻集群所有节点数据完全同步统一

  • 软状态：接纳短时间数据差异，依靠异步机制逐步完成数据对齐

• 实现方式

  • 异步数据复制：主节点写入数据后，异步推送数据至从节点完成同步

  • 集群同步协议：借助 Gossip 协议等完成分布式节点间数据互通

• 典型场景

  • 社交平台发布动态后，部分用户短暂看不到最新内容

  • 分布式多节点缓存之间的数据更新延迟

最终一致性

• 含义：若无新的数据写入操作，经过一段同步窗口期后，分布式集群内所有节点存储的数据，最终会达成完全一致的状态。

• 实现方式

  • 异步数据同步：数据完成写入后，异步向全集群节点传播推送

  • 数据冲突解决：采用 LWW（最后写入胜出）、数据合并等策略处理多节点数据冲突

  • 客户端主动重试：客户端读取到旧数据时，自动重试请求拉取最新数据

• 典型场景

  • DynamoDB 提供的最终一致性读取模式

  • Cassandra 先本地落库，再异步向集群其他节点同步数据

BASE 与 CAP

• CAP 定理：分布式系统无法同时满足一致性 C、可用性 A、分区容错性 P 三大特性，最多兼容两项。

• BASE 理论：专为 CAP 里 AP 架构 设计，放弃强一致性，依托三大核心特性实现高可用服务与最终数据一致。

  • AP 架构：优先保障可用性 A + 分区容错性 P，舍弃强一致性 C，业务层面采用 BASE 理论设计

  • CP 架构：优先保障一致性 C + 分区容错性 P，舍弃高可用性 A，使用强一致性方案，典型组件 ZooKeeper、Redisson

BASE 典型应用场景

BASE 的优缺点

优点

• 服务可用性高，故障场景下依旧可提供基础业务服务

• 系统横向扩展能力强，放宽数据实时一致限制，大幅提升整体吞吐量

• 环境适配性好，完美适配网络分区、节点波动等分布式常见异常场景

缺点

• 存在数据短暂不一致问题，用户可能临时查询到旧数据

• 架构开发难度提升，需要额外设计数据冲突处理、版本管控等逻辑

• 部分复杂业务场景，需要在业务代码中适配处理数据不一致带来的问题

BASE 与微服务

在微服务架构开发中，BASE 理论应用十分广泛：

• 服务异步通信：依托 Kafka、RabbitMQ、RocketMQ 等消息中间件，通过事件异步通信实现数据最终一致

• 分布式事务处理：采用 Saga 模式、TCC 模式落地柔性事务，放弃传统强一致性分布式事务

• 缓存数据一致：通过写穿透、缓存主动失效、延时更新等策略，协调数据库与分布式缓存的数据一致性

BASE 典型系统

跨服务最终一致性事务设计

核心设计原则

• 主动放弃事务强一致性，接纳短时数据不一致，依靠机制达成业务层面最终正确

• 优先保障业务基本可用，核心流程优先执行，非核心流程允许延迟处理

• 整体以异步化处理为核心，借助事件、消息实现微服务之间解耦调用

典型实现模式

事件驱动架构

1. 上游服务完成自身本地事务，执行对应核心业务操作

2. 业务完成后发布对应的领域业务事件

3. 下游服务订阅监听对应事件，消费事件并执行自身本地事务

4. 依靠消息队列保障事件可靠投递，所有消费服务统一实现接口幂等，杜绝重复执行问题

Saga 模式

1. 将整条跨服务长事务，拆分为多个独立的本地子事务

2. 每一个正向执行的本地事务，都配套设计对应的事务补偿回滚操作

3. 按照既定顺序正向依次执行所有子事务

4. 任意子事务执行失败时，逆向执行前置所有已完成事务的补偿操作，完成事务回滚

TCC 模式

1. Try 阶段：所有参与事务的服务统一完成资源预锁定、资源预留操作

2. Confirm 阶段：全部服务预留资源成功后，统一执行正式业务提交操作

3. Cancel 阶段：任意服务预预留失败，所有参与服务统一执行取消操作，释放已锁定资源

关键设计要点

• 幂等性设计：所有业务操作、事务操作必须支持幂等执行，依靠唯一业务编号、数据版本号规避重复处理

• 事件可靠性：配置消息重试机制与死信队列，保障业务事件不丢失、不遗漏

• 补偿机制规范：正向业务流程必须配套完整补偿流程，同时补偿操作同样保证幂等性

• 事务状态管控：引入状态机统一管理分布式事务全生命周期，明确各类状态流转规则

• 运维监控告警：实时监控 Saga、TCC 事务执行进度，针对超时、执行失败场景配置自动告警

典型应用场景

• 电商下单全流程：订单创建 → 库存扣减 → 支付确认，优先选用 Saga 模式实现

• 金融跨行转账：资金转出冻结 → 转入入账，资金类高严谨场景优先选用 TCC 模式

• 供应链业务流转：订单生成 → 物流调度 → 仓储备货，适配事件驱动架构

开发注意事项

• 摒弃传统本地事务强一致思维，贴合业务场景合理容忍数据短时不一致

• 依据业务容错能力，灵活选择 Saga、TCC、事件驱动等事务方案

• 针对网络中断、服务宕机、消息堆积等异常场景做全场景测试，验证事务补偿有效性

• 非核心业务流程尽量采用异步化剥离，缩短核心事务执行链路，提升整体响应速度