事务一致性比较：2PC、TCC、ES与读写分离、Sagas详解

本文档主要探讨了五种不同的事务一致性模型，分别是两阶段提交（2PC）、TCC（Try-Cancel-Confirm）、Event Sourcing以及两种不同的读写分离策略——直接读写和事件驱动。以下是每种模型的详细介绍： 1. **两阶段提交 (2PC)**: - **投票阶段**: 协调器向所有参与服务发送投票请求，服务响应yes或no。若有任何服务拒绝或超时，协调器进入决定阶段。 - **决定阶段**: 若所有服务同意，协调器执行commit，事务完成；若有失败，协调器可能需要重新协调或中止事务。这种协议可能导致数据库锁住资源并产生较高的通信复杂度。 2. **TCC (Try-Cancel-Confirm)**: - **尝试阶段**: 发起try请求，数据库设置为尝试状态。 - **确认阶段**: 如果所有服务成功，进行confirm操作，状态变为确认。若失败或超时，协调器尝试重试或执行回退操作。 - **优点**: 取消操作设计简洁，只需改变数据库状态；缺点是数据库需要额外的状态字段，并且接口复杂，涉及try、confirm和cancel三个操作，耗时且可能需要多次交互。 3. **Event Sourcing** (两种实现方式): - **演进流程step1**: 子服务按顺序执行业务操作，每个步骤写入业务数据库并发送消息。一旦某个服务失败，消息链会通知上层服务回滚。 - **优点**: 去中心化处理，容错性好；缺点是服务崩溃可能导致部分操作丢失，需要本地持久化消息和额外的event表。 - **演进流程step2**: 采用本地事务记录事件并写入event表，同时轮询更新状态。这样可以防止消息队列本地化崩溃，但增加了开发复杂性。 - **演进流程step3**: 使用本地数据库记录事件，提高了事务安全性，但对NoSQL数据库的交易和查询支持有限。 4. **读写分离** (未明确说明哪种策略，但提到了两种可能的方式)： - 直接读写分离：提高读取速度，但可能增加写入时的一致性问题。 - 事件驱动：写入事件到本地表，通过轮询更新状态，确保一致性，但要求开发者维护两个表，对特定类型的数据库不友好。 总结来说，这五种事务一致性模型各有优缺点，适用于不同场景和系统设计需求。选择合适的模型取决于系统的可扩展性、容错性、性能要求以及数据一致性保障的具体需求。理解这些模型的特性有助于开发者在实际项目中做出明智的决策。