java面试（消息队列MQ）

MQ有什么用？有哪些场景？

MQ（MessageQueue）消息队列。队列（FIFO）先进先出的数据结构，消息由生产者发送到MQ，后由消费者对消息进行处理。QQ，微信就是MQ场景。
MQ作用：

1. 异步。快递员 -> 菜鸟驿站 <-客户。作用：提高响应速度和吞吐量。
2. 解耦。java -> MQ ->Python。作用：服务间解耦，减少服务间影响，提高系统的稳定性和可扩展性。可一对多处理消息
3. 削峰填谷。瞬间流量 -> MQ -> 闲时处理。作用：以稳定系统对突发的流量冲击。
   MQ缺点：

• 系统可用性降低，MQ宕机整个业务产生影响。
• .系统的复杂度提高，引入MQ后，数据链路变得复杂。要保证消息不丢失，不重复调用，消息顺序性。
• 数据一致性，A系统发消息，需要B，C统一处理，B成功，C失败会造成数据一致性问题。

如何进行产品选型？

Kafka：吞吐量非常大，性能好，集群高可用。缺点：会丢失据，功能单一。场景：数据量大，丢失不影响。如日记，大数据采集
RabbitMQ：可靠性高，功能全面。缺点：吞吐量较低，消息积累影响性能。erlang语言不好优化。场景：小规模
RocketMQ：高吞吐，高性能，高可用，功能全面。缺点：开源版不如商业版。生态不成熟，只支持java。场景：几乎全场景。

如何保证消息不丢失？

1. 那个环节会造成消息丢失
   跨网络时会造成消息丢失
   
   1.1 生产者发消息
   1.2 主从同步
   1.3 硬盘同步消息
   1.4 消费者接收消息
2. 怎么防止消息丢失
   2.1 生产者消息不丢失
   kafka中消息发送+回调。
   RocketMQ：消息发送+回调+事务。
   
   RabbitMQ：消息发送+回调+手动事务(channel.txSelect()开启事务，channel.txCommit()提交事务，channel.txRollback()回滚事务)channel会阻塞，造成吞吐量下降。3.0升级为Publisher Confirm，整个处理流程通RocketMQ的事务消息。
   2.2 MQ主从同步不丢失
   RocketMQ：
   普通集群：同步同步(MQ主表同步分表后分表返回确认消息,会丢消息)，异步同步(主表获取到数据直接发返回确认消息,不会丢消息)。
   Dledger集群-两阶段提交：先在候选节点中选出master，设置为uncommited，等多数slave节点同步到消息设置master状态为commited状态
   RabbitMQ：
   普通集群：消息分散存储，节点不会主动进行消息同步，会丢失消息。
   镜像集群：镜像集群会在节点之间主动同步数据。
   Kafka：
   允许消息少量丢失，acks：0，1，all 同上面的同步同步，同步异步。
   2.3 MQ消息存盘不丢失
   RocketMQ：同步刷盘和异步刷盘（会丢失）。
   RabbitMQ：将队列配置成持久化队列。3.x版本新增Quorum队列会采用raft协议进行消息同步。
   2.4 MQ消费者消费消息不丢失
   RocketMQ：使用默认的同步方式消费，不采用异步先返回offset方式消费。
   RabbitMQ：autoCommit - 手动提交offset
   Kafka：手动提交offset

如何保证消息消费的幂等性

就是防止消费者重复消费。所有MQ并没有提供主动解决幂等性的机制，需要由消费者自行控制。
RocketMQ：给每个消息分配了MessageId，作为消费者判断幂等性的依据。最好使用带有业务标识的id替换。

如何保证消息的顺序

全局有序和局部有序：MQ只需要保证局部有序(微信聊天)，不需要保证全局有序（整个微信）。

生产者把一组有序的消息放在同一个队列中，而消费者一次消费整个队列中的消息。
RocketMQ中有完整设计，RabbitMQ和Kafka没有，需自己实现。
RabbitMQ：要保证目标exchange只对应一个队列，并且一个队列只对应一个消费者。
Kafka：生产者通过定制partition分配规则，将消息分配到同一个partition。Topic下只对应一个消费者。

如何保证消息的高效读写

Kafka和RocketMQ都是通过零拷贝实现。传统文件复制从（硬件-内核空间-用户空间-内核空间-硬件）需要四次拷贝。


Java对零拷贝进行了封装，mmap方式通过MappedByteBuffer对象进行操作，而transfer通过FileChannel进行操作。
mmap适合较小的文件，通常文件不超过1.5G~2G之间。Transfer没有文件大小限制。
RocketMQ：使用mmap方式对他的文件进行读写。commotLog，1G。
Kafka：他的index日志文件通过mmap方式读写，其他日志文件中，并没有使用零拷贝方式。使用transfile方式将硬盘数据加载到网卡。

如何使用MQ保证分布式事务的最终一致性。

分布式事务：业务相关的多个操作，保证他们同时成功或失败。
强一致性：任何时候多个操作都是对齐的。
最终一致性：多个操作最终结果时对齐的。
MQ中要保护事务的最终一致性，需要：

1. 生产者要保证100%消息投递。 - 事务消息机制
2. 消费者要保证幂等消费。 - 唯一id+业务自己实现
   分布式MQ的三种语义：
   at least once：消费者至少消费一次
   at most once：生产者最多发送一次
   exactly once：正确处理一次。Rocket并不能保证exactly once，商业版支持。kafka最新版提供了demo。RabbitMQ不支持。

如何设计一个MQ

1. 实现单机的blockQueue队列数据结构。队列可伸缩扩展。
2. 将单机队列扩展为分布式队列，将队列分布在不同的节点。就涉及到集群管理，kafka用zookeeper。
3. 基于Topic定制消息路由选择策略。默认轮询发送到不同队列中，RocketMQ使用MessageSelector顺序发送至同一个队列。为保证消息消费偏移量（消费进度）则需要和消费者之间形成多对一的关系。一个队列由一个消费者消费可保证消息先进先出是有保障的（同机房同网络优先）。
4. 消费消息时如果一个消费者对应多个队列，则并发多线程的获取消息，如果为保证顺序，则先把队列锁住依次消费。
5. 消费者路由策略
6. 实现高效的网络通信。 -Netty Http
7. 规划日志文件，实现文件高效读写。 -零拷贝，顺序写。服务重启后快速还原现场。
8. 定制高级功能。 死信队列，延迟队列，事务消息。