互联网一致性架构设计 -- 事务一致性
按业务区分
- 单库事务
- 多库事务
例子:用户下了一个订单,需要修改余额表,订单表,流水表
单库事务
start transaction; CURDtable t_account; any Exception rollback; CURDtable t_order; any Exceptionrollback; CURDtable t_flow; any Exceptionrollback; commit;
多库事务:将缘分一起执行的事务,拆分成多个小的
start transaction1; //第一个库事务执行 CURDtable t_account; any Exception rollback; … // 第一个库事务提交 commit1; start transaction2; //第二个库事务执行 CURDtable t_order; any Exceptionrollback; … // 第二个库事务提交 commit2; start transaction3; //第三个库事务执行 CURDtable t_flow; any Exceptionrollback; … // 第三个库事务提交 commit3;
结果:分库后分成了多个小的事务,就不能实现原子性,无法达到事务的效果。
优化方案
- 补偿事务
- 先执行完,最后一起提交
补偿事务
补偿事务是一种在业务端实施业务逆向操作事务,来保证业务数据一致性的方式。
例如:
举个栗子,修改余额表事务为 int Do_AccountT(uid, money){ start transaction; //余额改变money这么多 CURDtable t_account with money; anyException rollback return NO; commit; return YES; } 那么补偿事务可以是: int Compensate_AccountT(uid, money){ //做一个money的反向操作 returnDo_AccountT(uid, -1*money){ }
缺点:
- 不同的业务要写不同的补偿事务,不具备通用性
- 没有考虑补偿事务的失败
- 如果业务流程很复杂,if/else会嵌套非常多层
先执行完,最后一起提交
依然是这个拆分后的几个小事务
start transaction1; //第一个库事务执行 CURDtable t_account; any Exception rollback; … // 第一个库事务提交 commit1; start transaction2; //第二个库事务执行 CURDtable t_order; any Exceptionrollback; … // 第二个库事务提交 commit2; start transaction3; //第三个库事务执行 CURDtable t_flow; any Exceptionrollback; … // 第三个库事务提交 commit3;
优化前
trx1.exec(); trx1.commit(); trx2.exec(); trx2.commit(); trx3.exec(); trx3.commit(); 第一个事务执行200ms,提交1ms; 第二个事务执行120ms,提交1ms; 第三个事务执行80ms,提交1ms;
优化后
trx1.exec(); trx2.exec(); trx3.exec(); trx1.commit(); trx2.commit(); trx3.commit(); 第一个事务执行200ms; 第二个事务执行120ms; 第三个事务执行80ms; 第一个事务执行1ms; 第二个事务执行1ms; 第三个事务执行1ms;
为什么这么做?
优化前:第一个事务成功提交之后,最后一个事务成功提交之前,如果出现问题(例如服务器重启,数据库异常等),都可能导致数据不一致。这个时间比较长,共403ms。
优化后:第一个事务提交后的,最后一个事务提交前,这个时间比较短,共3ms,这样就能尽可能减少出现数据不一致的概率。而且还通用,减少编码量。
缺点:还是存在不一致的情况,但是已经大大降低。
两种优化方案的比较
事务提交时会释放数据库的连接,第一种方案,第一个库事务提交,数据库连接就释放了,后置事务提交的方案,所有库的连接,要等到所有事务执行完才释放。这就意味着,数据库连接占用的时间增长了,系统整体的吞吐量降低了。
相关推荐
### 微服务架构中的分布式事务处理机制 ...通过合理选择和运用TCC型分布式事务方案、最大努力通知方案、可靠消息服务等技术手段,结合Dubbo等成熟框架的支持,可以有效应对分布式环境下的事务一致性挑战。
GoldenDB分布式数据库的特点和设计:中兴通讯股份有限公司开发的GoldenDB分布式数据库,是为了满足金融行业对事务实时一致性、数据复制安全性和性能容量线性扩展的需求而设计的分布式交易型数据库。GoldenDB具备以下...
例如,InnoDB支持事务处理和外键约束,适用于需要高一致性和安全性的应用场景;而MyISAM则更适合于读多写少的场景,因其查询性能更优。 - **2.1.3 分布式数据库设计** - 对于大规模的数据集群,MySQL支持分布式...
3. 水平扩容:应用集群形成,可能引入DNS或负载均衡设备解决用户访问分配和Session一致性问题。 4. 读写分离:通过数据复制解决读压力,应用需要根据业务逻辑选择读库或主库。 5. 搜索引擎:引入搜索引擎提升查询...
- **数据一致性**:分布式系统中保持数据一致性的挑战,如使用分布式数据库或补偿事务。 - **监控与日志**:实施全面的监控和日志收集,以便快速定位和解决问题。 - **组织结构与文化**:需要匹配的敏捷开发团队...
在微服务架构下,事务一致性不仅涉及技术选型,还涉及到业务流程设计和异常处理策略。通过理解CAP和BASE理论,结合不同类型的分布式事务方案,开发者可以更好地应对复杂的事务一致性挑战,确保系统在分布式环境下的...
微服务架构中,分布式事务设计是解决多个服务间协作时数据一致性问题的关键。在微服务环境下,由于服务的独立部署和数据存储的分散,传统的单体应用中的ACID(原子性、一致性、隔离性和持久性)事务原则不再适用。...
除此以外还介绍了一些分布式事务相关的技术,如幂等性、全局一致性ID、分布式对象等。... 6-1 分布式事务介绍 6-2 spring分布式事务实现_使用JTA 6-3 spring分布式事务实现_不使用JTA 6-4 实例1-DB-DB 6-5 实例1-DB-...
### 从大型电商架构演进看互联网高可用架构设计 #### 一、互联网架构演进 **五种架构模型介绍** 1. **单体架构**:最初期的软件架构模式,将所有功能集成在一个紧密耦合的应用程序中。易于理解和部署,但随着系统...
标题中提到的“彻底搞定互联网架构中海量数据一致性”意味着本文将深入探讨如何在现代互联网架构中处理和维护海量数据集的一致性问题。在分布式系统中,数据一致性是一个核心难题,尤其当涉及跨多个服务器、数据中心...
通过这些知识点,我们可以总结出天鹅到家支付系统高可用架构设计的核心在于构建一个既能够处理高并发支付请求、又能保证数据一致性和系统稳定性的高效体系。这一架构通过引入了幂等性、分布式锁、TCC事务模式、MVCC...
《MySQL性能调优与架构设计》是简朝阳的一本专著,主要针对数据库管理员、开发人员和系统架构师,深入探讨了如何优化MySQL数据库的性能并进行合理的架构设计。书中涵盖了多个关键领域,旨在帮助读者提升数据库系统的...
Seata是一种在微服务架构下保证事务一致性的解决方案。Seata代表Simple Extensible Autonomous Transaction Architecture,意为简单、可扩展、自主的分布式事务架构。其主要作用是在微服务架构中,实现各个服务之间...
总的来说,在设计分布式系统时,事务一致性是一个需要深思熟虑的问题。系统架构师和开发人员需要根据应用场景的特点,综合考量CAP定律中的三个要素,选择合适的分布式事务处理方案。在保证系统可用性和分区容错性的...
在设计互联网数据库架构时,首要考虑的是系统的可用性和读写性能,同时也要处理一致性问题,确保扩展性和应对海量数据的处理能力。以下是对这些关键点的详细解析: 1. **可用性设计** - 通过复制和冗余来提高系统...
传统应用中,本地事务通过ACID(原子性、一致性、隔离性、持久性)原则保证数据的一致性,但在微服务架构中,由于服务间的解耦和数据库的分散,这种方法不再适用。分布式事务,如两阶段提交(2PC)协议,虽然能解决...
在互联网环境中,数据库架构设计是一项关键任务,它涉及到系统的可用性、读写性能、一致性以及扩展性等多个方面。本文主要探讨了几个关键的设计思路和解决方案。 1. 可用性设计: - 复制与冗余:为了提高可用性,...
总之,分布式事务架构设计是解决大规模分布式环境下的数据一致性问题的关键,涉及到对CAP原理的理解和应用,以及对ACID原则的妥协。通过各种策略和机制,如本地消息表、消息中间件、幂等性设计和补偿事务,可以有效...
3. 微服务挑战:服务发现、接口定义、数据一致性、事务处理、监控和故障隔离等问题需要解决。 4. 微服务设计原则:单一职责原则、服务自治、服务间通信、持续交付和部署、基础设施自动化、业务能力导向等。 三、从...