深圳网站建设 卓越创,商业网站开发岗位需求分析,做生意网站,打开2345网址典型回答
分布式事务是指在分布式系统中涉及到多个数据库或多个应用程序之间的事务处理#xff0c;这些数据库或应用程序可能分布在不同的物理节点上#xff0c;甚至可能位于不同的地理位置。在分布式事务中#xff0c;需要确保所有参与者的事务操作都能够保持一致性#…典型回答
分布式事务是指在分布式系统中涉及到多个数据库或多个应用程序之间的事务处理这些数据库或应用程序可能分布在不同的物理节点上甚至可能位于不同的地理位置。在分布式事务中需要确保所有参与者的事务操作都能够保持一致性即所有参与者的事务要么全部提交成功要么全部回滚。 举个例子假设一个电商系统用户下单后需要扣减库存、扣减账户余额、生成订单等操作。在单机环境下可以将这些操作放在同一个事务中保证原子性、一致性和持久性。但在分布式环境下可能存在多个服务(如库存服务、账户服务、订单服务)分布在不同的物理节点上此时需要确保所有服务操作的事务都能够同步进行避免出现数据不一致的情况。 为了解决分布式事务的问题出现了一些分布式事务解决方案如XA协议、TCC事务、最大努力通知等。这些解决方案的实现方式各不相同但都需要考虑如何确保所有参与者的事务操作能够保持一致性以及如何处理可能出现的异常情况。
常见的分布式事务有哪些?
分布式事务的目的是保证分布式系统中的多个参与方的数据能够保证一致性。即所有参与者在一次写操作过程中要么都成功要么都失败。 至于这个一致性到底是怎样的一致性是强一致性、还是最终一致性不同的分布式事务方案其实达到的效果并不相同。 如果想要实现强一致性那么就一定要引入一个协调者通过协调者来协调所有参与者来进行提交或者回滚。所以这类方案包含基于XA规范的二阶段及三阶段提交、以及支持2阶段提交。
1、有了2阶段提交为什么还需要3阶段提交?
阶段提交(Two-phaseCommit)是XA分布式事务中一个重要的方案二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。 所谓的两个阶段是指:第一阶段:准备阶段(投票阶段)和第二阶段:提交阶段(执行阶段)。但是2PC本身存在着同步阻塞问题、单点故障问题、数据不一致问题等所以在二阶段的基础上增加了一个预提交的阶段组成了3阶段提交的方案。 如果想要实现最终一致性那么方案上就比较简单常见的基于可靠消息的最终一致性(本地消息表、事务消息)、最大努力通知等 如何基于本地消息表实现分布式事务?
本地消息表其实也是借助消息来实现分布式事务的。 这个方案的主要思想是将分布式事务拆分为本地事务和消息事务两个部分本地事务在本地数据库中进行提交或回滚而消息事务则将消息写入消息中间件中以实现消息的可靠投递和顺序性。 般来说的做法是在发送消息之前先创建一条本地消息并且保证写本地业务数据的操作和写本地消息记录的操作在同一个事务中。这样就能确保只要业务操作成功本地消息一定可以写成功。 然后再基于本地消息调用MQ发送远程消息。 消息发出去之后等待消费者消费在消费者端接收到消息之后做业务处理处理成功后再修改本地消息表的状态。 这个过程中可能有几个步骤都可能发生失败那么如果失败了怎么办呢?
1、2如果失败因为在同一个事务中所以事务会回滚3及以后的步骤都不会执行。数据是一致的。 3如果失败那么就需要有一个定时任务不断的扫描本地消息数据对于未成功的消息进行重新投递 5如果失败则依靠消息的重投机制不断地重试。 6、7如果失败那么就相当于两个分布式系统中的业务数据已经一致了但是本地消息表的状态还是错的。这种情况也可以借助定时任务继续重投消息让下游幂等消费再重新更改消息状态或者本系统也可以通过定时任务去查询下游系统的状态如果已经成功了则直接推进消息状态即可。 可靠消息实现最终一致性的方案其实就是借助支持事务消息的中间件通过发送事务消息的方式来保证最终一致性过程及原理可以参考:
RocketMQ的事务消息是如何实现的?
RocketMQ的事务消息是通过TransactionListener接囗来实现的。 在发送事务消息时i首先向RocketMQ Broker发送一条“half消息”(即半消息)半消息将被存储在Broker端的事务消息日志中但是这个消息还不能被消费者消费。 接下来在半消息发送成功后应用程序通过执行本地事务来确定是否要提交该事务消息。 如果本地事务执行成功就会通知RocketMQ Broker提交该事务消息使得该消息可以被消费者消费;否则就会通知RocketMQ Broker回滚该事务消息该消息将被删除从而保证消息不会被消费者消费。 拆解下来的话主要有以下4个步骤:
发送半消息:应用程序向RocketMQ Broker发送一条半消息该消息在Broker端的事务消息日志中被标记为prepared”状态.执行本地事务:RocketMO会通知应用程序执行本地事务。如果本地事务执行成功应用程序通知RocketMQ Broker提交该事务消息提交事务消息:RocketMO收到提交消息以后会将该消息的状态从“prepared”改为“committed”并使该消息可以被消费者消费回滚事务消息:如果本地事务执行失败应用程序通知RocketMQ Broker回滚该事务消息RocketMQ将该消息的状态从“prepared”改为“rollback”并将该消息从事务消息日志中删除从而保证该消息不会被消费者消费。 另外还有我们比较熟知的TCC他也是最终一致性的一种实现方案。只不过他比基于消息的最终一致性要稍微更加靠近强一致性一些。或者说他的不一致性的时长会更短。
什么是TCC和2PC有什么区别?
TCC是Try-Confirm-Cancel的缩写它是一种分布式事务解决方案采用了基于业务逻辑的补偿机制将整个分布式事务分解为若干个子事务每个子事务都有一个try、confirm和cancel三个操作通过这些操作来实现分布式事务的执行和回滚 具体来说TCC事务包括以下三个步骤:
Try:在try阶段参与者尝试执行本地事务并对全局事务预留资源。如果try阶段执行成功参与者会返回一个成功标识否则会返回一个失败标识。Confirm:如果所有参与者的try阶段都执行成功则协调者通知所有参与者提交事务那么就要执行confirm阶段这时候参与者将在本地提交事务并释放全局事务的资源Cancel:如果任何一个参与者在try阶段执行失败则协调者通知所有参与者回滚事务。那么就要执行cancel阶段。
以下是一个简单的TCC事务的例子假设有一个转账服务需要从A账户中转移到B账户中100元、C账户中200元:
Try阶段:转账服务首先尝试将A账户的金额冻结300元Confirm阶段:如果所有的try操作都执行成功转账服务将尝试执行解冻并转账将金额转到B账户和C账户中Cancel阶段:如果try过程中某个转账事务执行失败。那么将执行解冻将300元解冻。如果在confirm过程中A-C的转账成功但是A-B的转账失败则再操作一次C-A的转账将钱退回去。
TCC这种事务方案有以下优缺点:
优点:
灵活性:TCC适用于不同类型的业务场景例如账户转账、库存扣减等能够根据业务逻辑实现精细的事务控制。高可用性:TCC使用分布式锁来保证分布式事务的一致性即使其中一个节点出现故障也不会影响整个系统的运行。可扩展性:TCC采用分阶段提交的方式支持向扩展可以适应更多的并发访问和业务场景。4.性能:TCC相对于2PC来说具有更好的性能表现
缺点:
实现复杂:TCC需要实现Try、Confirm和Cancel三个操作每个操作都需要实现正确的业务逻辑和补偿机制代码实现比较复杂。存在悬挂事务问题:TCC的实现方式存在悬挂事务的问题即在执行过程中可能会有部分子事务成功而其他子事务失败导致整个事务无法回滚或提交。空回滚问题:TCC中的Try过程中有的参与者成功了有的参与者失败了这时候就需要所有参与者都执行Cancel这时候对于那些没有Ty成功的参与者来说本次回就是一次空回滚。需要在业务中做好对空回滚的识别和处理否则就会出现异常报错的情况甚至可能导致Cancel一直失败最终导致整个分布式事务失败。业务代码侵入性:TCC需要将事务操作拆分为Try、Confirm和Cancel三个步骤对业务代码有一定的侵入性需要针对不同的业务场景进行实现。 另外还有一些分布式事务的组件如Seata他其实是一个开源的分布式事务解决方案旨在为微服务架构提供高效且透明的事务管理。在讨论 Seata 的一致性特性时需要明确其支持的不同事务模式因为每种模式对一致性的保证不同。
什么是Seata?他有哪几种模式?
Seata是一个阿里开源的分布式事务解决方案(Simple Extensible Autonomous Transaction Architecture)用于在分布式系统中实现分布式事务。它旨在简化分布式事务的开发和管理帮助解决分布式系统中的数据一致性问题。
Seata的实现原理
因为Seata的开发者坚定地认为:一个分布式事务是有若干个本地事务组成的。所以他们给Seata体系的所有组件定义成了三种分别是Transaction Coordinator、Transaction Manager和Resource Manager [ransaction Coordinator(TC):这是一个独立的服务是一个独立的JM 进程里面不包含任何业务代码它的主要职责:维护着整个事务的全局状态负责通知 RM 执行回滚或提交; [ransaction Manager(TM):在微服务架构中可对应为聚合服务即将不同的微服务组合起来成一个完成的业务流程TM 的职责是开启一个全局事务或者提交或回滚一个全局事务; Resource Manager(RM):RM 在微服务框架中对应具体的某个微服务为事务的分支RM 的职责是:执行每个事务分支的操作。
