面试

大厂面试系列(九):MQ和分布式事务

2020-11-12  本文已影响0人  赵镇

MQ和分布式事务

MQ

分布式事务

首先来一个具体的解决方案的示例

      *  1、两阶段提交(2PC) 第一阶段:事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是否可以提交. 第二阶段:事务协调器要求每个数据库提交数据。 优点: 尽量保证了数据的强一致,适合对数据强一致要求很高的关键领域。(其实也不能100%保证强一致) 缺点: 实现复杂,牺牲了可用性,对性能影响较大,不适合高并发高性能场景,如果分布式系统跨接口调用,目前 .NET 界还没有实现方案。 
      * 2、补偿事务(TCC) 针对每个操作,都要注册一个与其对应的确认和补偿(撤销)。Try、Confirm、Cancel 优点: 跟2PC比起来,实现以及流程相对简单了一些,但数据的一致性比2PC也要差一些 缺点: 缺点还是比较明显的,在2,3步中都有可能失败。TCC属于应用层的一种补偿方式,所以需要程序员在实现的时候多写很多补偿的代码,在一些场景中,一些业务流程可能用TCC不太好定义及处理。 
      * 3、本地消息表(异步确保) 核心思想是将分布式事务拆分成本地事务进行处理,消息生产方,需要额外建一个消息表,并记录消息发送状态。消息表和业务数据要在一个事务里提交,也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败,会进行重试发送。 优点: 一种非常经典的实现,避免了分布式事务,实现了最终一致性。在 .NET中 有现成的解决方案。 缺点: 消息表会耦合到业务系统中,如果没有封装好的解决方案,会有很多杂活需要处理。 
      * 4、MQ事务消息 RocketMQ支持,RabbitMQ 和 Kafka 都不支持,一次发送消息和一次确认消息,生产方需要实现一个check接口(确认消息或者回滚) 优点: 实现了最终一致性,不需要依赖本地数据库事务。 缺点: 实现难度大,主流MQ不支持,没有.NET客户端,RocketMQ事务消息部分代码也未开源。 
      * 5、Sagas事务模型 长时间运行的事务,该模型其核心思想就是拆分分布式系统中的长事务为多个短事务,或者叫多个本地事务,然后由 Sagas 工作流引擎负责协调,如果整个流程正常结束,那么就算是业务成功完成,如果在这过程中实现失败,那么Sagas工作流引擎就会以相反的顺序调用补偿操作,重新进行业务回滚。 
上一篇 下一篇

猜你喜欢

热点阅读