现代大型互联网系统已经告别了单机时代,微服务、负载均衡、分布式已经成为主流。在分布式系统中,对于数据库的关键操作,也需要使用事务来保证业务结果,如银行转账、交易扣款等。单机的事务可以通过数据库事务或 Spring 事务来实现,分布式系统则更复杂,涉及多机房、多数据源。
分布式事务也需要满足事务的基本特性,包括原子性、一致性、隔离性、持久性。事务中的一系列操作,要么全部成功,要么全部失败。在分布式事务中,最大的挑战是一致性,要求系统中所有的数据存储保持一致。一致性满足 CAP 原则,即 Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)不能同时满足。Consistency 指同一时间系统中数据保持一致,Availability 指部分节点异常后能否正常提供服务,Partition tolerance 指数据不一致形成分区后能否正常提供服务。
目前业界对分布式事务已形成 BASE 理论共识,即 Basically Available(基本可用),Soft State(软状态)和 Eventual Consistency(最终一致性)。BASE 理论延伸了 CAP 原则,在系统出现部分节点故障时允许损失部分可用性,允许出现中间状态,并使用一些手段保证最终数据的一致性。基于 BASE 理论设计的系统,能够接受短暂时间的数据不一致,流程设计上要确保这个不一致不能影响业务。
两阶段提交就是把数据处理过程分为两个阶段。使用一个独立的事务管理器,在第一阶段(prepare)向子系统发起事务请求,询问各个子系统是否就绪,根据子系统的响应决定第二阶段(commit/rollback)是否提交事务或者回滚。如果第一阶段所有子系统都就绪,则第二阶段提交事务;如有子系统未就绪,则第二阶段所有子系统进行回滚。
两阶段提交方案最大的问题是存在阻塞和不一致风险。若事务管理器故障,将导致整个系统不可用。如果第二阶段事务管理器或子系统异常,最终结果可能无法确定。
三阶段提交方案,是把两阶段提交方案的第一步再次细分为两步。第一阶段(CanCommit),事务管理器询问子系统是否可以执行事务,得到全部肯定答复后,在第二阶段(PreCommit)向子系统发起事务请求,然后在第三阶段(DoCommit)提交或者回滚。
TCC 方案,全称是 try-confirm-cancel,各阶段含义是:
假设系统 A、系统 B 是分布式事务的参与者。
使用本地消息表方案,要求系统 A 和系统 B 支持幂等,并且系统 A 能够进行回滚。
可靠消息方案通过消息队列来保证分布式事务。流程如下:
尽最大努力通知,就是系统 A 执行成功后,发送消息,通知服务消费消息并调用系统 B,如果系统 B 执行成功则流程结束,否则会尽量调用 B 进行重试,失败到一定次数后,放弃本次事务。
分布式事务很难做到实时一致性,总的来说主要是保证最终一致性。在技术设计中,需要充分考虑中间状态,确保中间状态不影响业务,确保系统可用性。
本文来源:程序之心,转载请注明出处!
主要介绍了计算机系统的基本概念,包括最底层的内存中的数据表示、流水线指令的构成、虚拟存储器、编译系统、动态加载库,以及用户应用等。书中提供了大量实际操作,可以帮助读者更好地理解程序执行的方式,改进程序的执行效率。此书以程序员的视角全面讲解了计算机系统,深入浅出地介绍了处理器、编译器、操作系统和网络环境,是这一领域的权威之作。
最新内容
© 2016 - 2024 chengxuzhixin.com All Rights Reserved.