文章目录
- 前言
- 分布式事务-基本信息
- 1. 两阶段提交(2PC)
- 2. 三阶段提交(3PC)
- 3. TCC模式
- 4. 可靠消息最终一致性
- 5. 优缺点与应用场景
- 5.1. 两阶段提交(2PC)
- 5.2. 三阶段提交(3PC)
- 5.3. TCC模式
- 5.4. 可靠消息最终一致性
- 6. 总结
前言
如果您觉得有用的话,记得给博主点个赞,评论,收藏一键三连啊,写作不易啊^ _ ^。
而且听说点赞的人每天的运气都不会太差,实在白嫖的话,那欢迎常来啊!!!
分布式事务-基本信息
分布式事务是指在分布式系统中,多个独立的数据库或系统参与同一个事务,以确保数据的一致性和完整性。
1. 两阶段提交(2PC)
2PC由协调者控制,分为两个阶段:
-
准备阶段:协调者向所有参与者发送准备请求,参与者执行事务操作但不提交。
-
提交阶段:协调者根据所有参与者的反馈决定提交还是回滚事务。
2PC的特点是简单直接,但存在单点故障和阻塞问题。
2. 三阶段提交(3PC)
3PC在2PC的基础上增加了一个准备确认阶段,减少阻塞:
-
准备阶段:协调者询问参与者是否可以提交事务。
-
预提交阶段:所有参与者都同意后,协调者发送预提交请求,参与者预提交事务。
-
提交阶段:协调者通知参与者提交事务。
3PC通过增加阶段减少了协调者和参与者的阻塞风险,但实现复杂度更高。
3. TCC模式
TCC(Try-Confirm/Cancel)模式的三阶段与2PC和3PC有所区别:
-
Try阶段:尝试执行业务操作并预留资源,不做实际提交。
-
Confirm阶段:确认提交,如果Try阶段成功,实际执行业务操作。
-
Cancel阶段:取消操作,如果Try阶段失败或业务异常,回滚预留资源。
TCC模式主要用于应用层的事务控制,由应用逻辑负责实现每个阶段的操作。它相比2PC和3PC,更灵活但也更复杂,因为需要开发者自己实现Try、Confirm和Cancel逻辑。
4. 可靠消息最终一致性
可靠消息最终一致性可靠消息最终一致性通过消息中间件来确保事务的一致性,其过程如下:
-
本地事务和消息发送:发送方在本地事务中发送消息到消息中间件,并标记为待确认。
-
消息确认:消息中间件保证消息可靠传递给接收方,接收方处理后反馈确认。
-
定期检查和重试:消息中间件会对未确认的消息进行重试,直到收到接收方确认,确保最终一致性。
这种模式不属于2PC和3PC,而是通过异步消息和重试机制来实现一致性,适用于对一致性要求不高但对性能要求较高的场景。
5. 优缺点与应用场景
5.1. 两阶段提交(2PC)
优点:
- 简单易实现:协议简单,参与者只需遵守协调者的指令。
- 保证一致性:能够确保所有参与者在事务完成后达到一致状态。
缺点:
-
阻塞问题:如果协调者在提交阶段崩溃,参与者会被阻塞在准备状态,直到协调者恢复。
-
单点故障:协调者是单点,如果它故障,整个事务系统无法运行。
-
性能开销:在提交过程中,所有参与者都需要等待协调者的指令,性能较低。
应用场景:
-
金融交易系统:需要确保所有相关账户的状态一致,适用于对强一致性要求高的场景。
-
分布式数据库:需要确保多个数据库实例之间的数据一致性。
5.2. 三阶段提交(3PC)
优点:
-
减少阻塞:通过增加准备确认阶段,减少参与者等待的时间,减少阻塞风险。
-
更高的容错性:相比2PC,更能应对协调者的故障。
缺点:
-
复杂性增加:引入了额外的阶段和消息通信,协议实现更加复杂。
-
性能开销:和2PC一样,仍然有较高的性能开销,增加的阶段也会增加延迟
应用场景:
-
分布式数据库:在需要进一步降低阻塞风险的分布式数据库系统中使用。
-
关键性金融交易:需要在高一致性和高可用性之间取得平衡的场景。
5.3. TCC模式
优点:
-
高灵活性:开发者可以根据具体业务场景定制Try、Confirm和Cancel逻辑,灵活性高。
-
高性能:相比2PC和3PC,不需要等待协调者的指令,性能更好。
-
解耦业务逻辑:将资源预留、提交和取消分开,有助于业务逻辑的解耦。
缺点:
-
开发复杂度高:需要开发者自己实现每个阶段的逻辑,增加开发复杂度。
-
资源预留挑战:需要考虑资源预留的有效性和安全性,避免资源浪费和竞争问题。
应用场景:
-
电子商务:订单创建、库存扣减和支付等操作需要跨多个系统,适合使用TCC模式。
-
金融业务:需要确保多步骤操作的一致性和灵活性,如贷款审批和放款。
5.4. 可靠消息最终一致性
优点:
-
异步处理:消息传递和事务处理异步进行,性能较高。
-
高可用性:消息中间件提供重试和确认机制,能够确保消息最终被处理,系统更加健壮。
-
适用广泛:适用于对强一致性要求不高但需要高性能的场景。
缺点:
-
最终一致性:只能保证最终一致性,不能保证瞬时一致性,可能会有短暂的不一致状态。
-
消息中间件依赖:依赖可靠的消息中间件,需要对消息系统进行监控和管理。
-
复杂性增加:涉及到消息的发送、接收、确认和重试逻辑,增加了系统复杂性。
应用场景:
-
微服务架构:在微服务间通过消息队列进行通信,适用于订单处理、用户注册等操作。
-
大数据处理:异步处理大量数据,确保最终一致性,如日志收集和分析系统。
6. 总结
特性 | 二阶段提交 | 三阶段提交 | TCC模式 | 可靠消息最终一致性 |
---|---|---|---|---|
一致性 | 强一致性 | 强一致性 | 强一致性 | 最终一致性 |
复杂性 | 低 | 高 | 高 | 中等 |
性能 | 低 | 中等 | 高 | 高 |
阻塞问题 | 是 | 减少 | 无 | 无 |
单点故障 | 是 | 否 | 否 | 无 |
适用场景 | 强一致性要求高 | 强一致性要求高且容错性要求高 | 复杂业务逻辑 | 性能要求高,最终一致性场景 |