- 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工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。
- 分布式事务了解吗？有哪些处理方法？
- 项目中有分布式事务处理吗？有哪些常见的分布式事务处理方式？说一下你们在项目中怎么用的。
- 分布式情况下如何保证事务。 如何设计实现一个分布式事务
- 分布式事务的各种方案及你的最佳方案
- 分布式事务是什么
- 什么是分布式事务？分布式事务如何保证数据一致性？
- 分布式事务知道吗?你们怎么解决的?TCC?那若出现网络原因,网络连不通怎么办啊
- 对分布式事务的理解
- 分布式事务的原理，如何使用分布式事务
- 多个服务之间调用的数据一致性问题，A服务中调用B服务 、C服务，B成功 C失败怎么解决？ 其实归根到底就是分布式事务的数据一致性解决方案，失败了数据怎么回滚
- 分布式事务的实现方式，分布式锁，分布式一致性，redis分布式锁；
- 分布式事务了解吗？你们项目中都用到了哪些分布式事务？都有哪些优缺点？
- 简单实现分布式事务