大厂面试系列(九)：MQ与分布式事务

zhaozhen

发布于 2021-07-15 10:37:22

7430

发布于 2021-07-15 10:37:22

文章被收录于专栏：微瞰Java后端开发微瞰Java后端开发

MQ和分布式事务

MQ

项目中RabbitMQ实现了at least once,包括mq反馈provider,消息持久化,consumer主动反馈mq.线程池消费防止消息积压等
mq 通知时，消费者没消费到怎么办
简单聊聊消息中间件？
你了解那些具体的消息中间件产品？
mq的消费端是怎么处理的？整理一下你的消费端的整个处理逻辑流程，然后说说你的ack是在哪里返回的。按照你这样画的话，如果数据库突然宕机，你的消息该怎么确认已经接收？那如果发送端的服务是多台部署呢？你保存消息的时候数据库就一直报唯一性的错误？
rocketmq用在什么场景。如果消费者组A下面有两个消费者组A1,A2,问消费者A1和A2能否消费不同的topic ?rocketmq如何保证的事务。
kafka,activemq,rabbitmq,rocketmq都有什么优点,缺点啊?
如果让你写一个消息队列，该如何进行架构设计啊?说-下你的思路
用过哪些MQ，怎么用的，和其他mq比较有什么优缺点，MQ的连接是线程安全的吗 ?MQ系统的数据如何保证不丢失
mq 通知时，消费者没消费到怎么办
mq的p2p模式
mq消息的幂等性如何保证？mq如何保证顺序消费？
MQ怎样保证消息的可靠性以及当时如何做消息幂等处理的
如何确保消息正确地发送至RabbitMQ？如何确保消息接收方消费了消息？如何避免消息重复投递或重复消费？消息基于什么传输？消息如何分发？消息怎么路由？如何确保消息不丢失？使用RabbitMQ有什么好处？rabbitmq的集群。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工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。