4. 数据不一致问题根因分析：缓存与数据库不一致、下游服务返回脏数据、并发写冲突、分布式事务缺失
在 BFF 聚合服务中，数据不一致是比接口超时更隐蔽、更难复现的故障类型。用户可能看到“订单已支付”但“库存未扣减”，或者“修改成功”后刷新页面数据回滚。这类问题的根因通常集中在四个维度：缓存与数据库不一致、下游服务返回脏数据、并发写冲突以及分布式事务缺失。本节将逐一拆解其产生机理与排查路径。
4.1 缓存与数据库不一致
BFF 层常使用 Redis 或本地缓存来降低下游服务压力。当缓存更新策略设计不当，或缓存与数据库的更新顺序出现时序错乱时，就会产生数据不一致。
下表对比了三种常见缓存更新策略及其不一致风险：
| 策略 | 执行顺序 | 不一致风险 | 适用场景 |
|---|---|---|---|
| Cache-Aside（旁路缓存） | 读：先查缓存，miss 则查 DB 并回写缓存 写：先更新 DB，再删除缓存 |
删除缓存失败或并发读写导致缓存与 DB 短暂不一致 | 读多写少，可接受短暂不一致 |
| Read-Through（穿透读） | 读请求由缓存组件负责回源 DB 并更新缓存 | 缓存组件与 DB 之间无原子性保证，回源期间数据可能被修改 | 缓存层封装度高的系统 |
| Write-Through（穿透写） | 写请求先写缓存，缓存同步写 DB | 缓存写成功但 DB 写失败，导致缓存与 DB 永久不一致 | 对一致性要求极高，且 DB 写入成功率有保障 |
下图展示了 Cache-Aside 策略下，因并发读写导致缓存写入旧值的不一致时序：
4.2 下游服务返回脏数据
BFF 聚合多个下游服务的数据时，如果某个下游服务内部存在数据同步延迟、主从读写分离或自身缓存未及时刷新，就会返回脏数据。BFF 层通常无法感知数据是否“脏”，只能被动透传。
下游服务返回脏数据的常见原因包括：
- 主从延迟：下游服务写入主库后，读请求落到从库，从库尚未同步最新数据。
- 本地缓存过期策略不当：下游服务内部缓存 TTL 设置过长，导致 BFF 持续获取旧数据。
- 异步消息未消费：下游服务 A 发送消息通知下游服务 B 更新数据，但消息队列积压，B 尚未处理。
- 批量更新未原子化：下游服务在一次请求中更新多个表，部分成功部分失败，未做回滚。
下图展示了 BFF 从两个下游服务获取数据时，因下游服务 B 返回脏数据导致聚合结果不一致的流程：
4.3 并发写冲突
当多个请求同时修改同一份数据时，如果没有合适的并发控制机制，就会发生写冲突，导致部分更新丢失或数据状态错乱。BFF 层作为聚合入口，常常同时接收来自不同客户端或不同模块的写请求。
并发写冲突的三种常见模式：
| 模式 | 描述 | 典型后果 |
|---|---|---|
| 丢失更新（Lost Update） | 两个写请求先后读取同一数据，各自修改后写回，后写的覆盖先写的 | 先提交的修改被覆盖，用户看到“修改成功”但实际数据未生效 |
| 脏写（Dirty Write） | 一个事务写入了未提交事务的中间数据 | 数据完整性被破坏，出现逻辑上不可能的组合状态 |
| 写偏斜（Write Skew） | 两个事务分别读取不同的数据子集，各自做局部更新，整体违反业务约束 | 例如：两人同时请假，系统检查各自剩余假期足够，但合并后总假期超限 |
解决并发写冲突的常用手段：
- 乐观锁（版本号/时间戳）：更新时检查版本号是否与读取时一致，不一致则重试或报错。
- 悲观锁（分布式锁）：对关键资源加锁，确保同一时间只有一个写请求能操作。
- 原子化操作：使用 Redis 的 INCR、CAS 或数据库的原子更新语句，避免读取-修改-写入的竞态窗口。
4.4 分布式事务缺失
BFF 聚合服务的一个核心挑战是：一次用户请求往往需要跨多个下游服务完成数据变更。如果缺乏分布式事务保障，部分服务成功、部分服务失败，就会导致全局数据不一致。
分布式事务缺失的典型表现：
- 下单场景：BFF 调用订单服务创建订单成功，调用库存服务扣减库存失败，但订单已生成，用户看到“下单成功”但实际无库存。
- 转账场景：BFF 调用账户服务 A 扣款成功，调用账户服务 B 加款失败，资金丢失。
- 发布场景：BFF 调用内容服务保存文章成功，调用搜索服务建立索引失败，文章无法被搜索到。
下表对比了四种分布式事务方案的适用性与一致性保证：
| 方案 | 一致性模型 | 性能影响 | BFF 层适用性 |
|---|---|---|---|
| XA 两阶段提交（2PC） | 强一致性 | 高（锁资源、阻塞） | 不推荐，BFF 层通常不直接管理数据库资源 |
| TCC（Try-Confirm-Cancel） | 最终一致性 | 中（需实现补偿逻辑） | 适合 BFF 层编排多个下游服务 |
| Saga（ choreography / orchestration） | 最终一致性 | 低（异步、非阻塞） | 非常适合 BFF 层，通过事件驱动或编排器协调 |
| 本地消息表 + 消息队列 | 最终一致性 | 低（异步） | 适合 BFF 层与下游服务通过 MQ 解耦的场景 |
下图展示了 BFF 层使用 Saga 编排模式处理跨服务写操作的流程，以及事务缺失时的数据不一致风险点：
4.5 根因排查路径总结
当 BFF 聚合服务出现数据不一致时，建议按以下路径逐层排查：
- 确认不一致范围：是单用户还是全局？是特定接口还是所有写接口？
- 检查缓存策略：对比缓存与数据库的值，确认是否存在缓存未更新或写入旧值的情况。
- 验证下游数据源：直接调用下游服务接口，确认其返回的数据是否与 BFF 聚合结果一致，排除脏数据透传。
- 分析并发写日志：查看同一数据在短时间内的修改记录，检查是否存在版本号冲突或更新覆盖。
- 审查分布式事务实现：确认 BFF 层是否对跨服务写操作使用了 Saga、TCC 或消息表等机制，以及补偿逻辑是否完整。