最近技术圈有个论调，大意是“分布式事务已死，一致性边界才是王道”。这种观点看似新颖，实则混淆了执行手段与指导思想。要看透这场争论，我们必须拨开迷雾，从最原始的事务需求聊起。
一、 事务的本质：对“确定性”的极度渴望
无论是在单机还是分布式环境，我们对事务的需求始终如一：在不确定的环境中，追求结果的确定性。
这种确定性表现为：多个操作要么一起成功，要么一起失败。如果没有事务，系统就会产生“中间状态”——钱扣了订单没生成、库存减了支付没成功。这种状态对业务来说是不可接受的“灾难”。
二、 单机时代：上帝视角的“完美复刻”
在单机数据库（如 MySQL）里，实现这种确定性的方案非常优雅：
- 第三方记录：数据库利用 Undo/Redo Log 充当了那个记录“中间状态”的第三方。
- 锁机制：通过锁来隔离并发，确保在事务完成前，外界看不到那个不稳定的“中间态”。
此时，事务的实现是内聚的。数据库既是执行者，也是监督者，拥有绝对的控制权。
三、 分布式困局：破碎的原子性
当系统演进到微服务或分库分表后，单机数据库的“上帝视角”消失了。
- 信息不对称：节点 A 并不知道节点 B 的死活。
- 通信不可靠：网络抖动让“确定性”变得极其昂贵。
分布式事务的出现，本质上是在跨网络环境下，试图通过“外挂”一个第三方组件，人为构建出一套类似单机事务的逻辑闭环。
- 2PC (二阶段提交) ：试图在多个节点间强行同步。协调者（第三方）先问大家“准备好了吗？”，再下达“执行”指令。它在分布式环境下复刻了单机的“强锁”机制。
- TCC (Try-Confirm-Cancel) ：将单机的日志逻辑搬到了业务层。
Try是资源预留，Confirm是确认提交，Cancel就是业务侧的 Undo 日志。
四、 认知升华：一致性边界是业务的“取舍”
回到开头的争议。为什么有人推崇“一致性边界”而否定“分布式事务”？
其实，一致性边界（Consistency Boundary）是一个业务概念，它定义了“哪里需要划线”；而分布式事务是一个技术概念，它解决了“这根线怎么划”。
随着业务规模扩大，我们发现强行追求全链路的“原子性”代价太高（性能骤降、可用性降低）。于是，架构演进出了不同的策略：
- 边界内（强一致） ：在核心金融链路，我们必须划定严格的边界，使用分布式事务协议（如 XA 或 Seata 的 AT 模式）确保万无一失。
- 边界外（柔性事务） ：在推荐系统、积分更新等场景，我们将边界放宽，接受暂时的“中间状态”，通过 Saga 补偿或可靠消息实现最终一致。
五、 总结：万变不离其宗
分布式数据库与分布式事务并非没关系，前者是后者的工程化实现。
技术名词会不断演进，但底层逻辑从未改变：所有的架构设计，本质上都是在识别业务的一致性边界，并从工具箱里挑选最合适的协议（2PC/TCC/Saga）去管理那个不稳定的中间状态。
与其追逐“一致性边界”这种新词，不如深刻理解事务的原理。毕竟，战略可以天马行空，但战术必须脚踏实地。
