消息队列

1. 什么是消息队列2. 消息队列有哪些使用场景

2.1 消息通讯 3. 消息队列如何解决消息丢失问题

3.1 生产者保证不丢消息3.2 存储端不丢消息3.3 消费阶段不丢消息 4. 消息队列如何保证消息的顺序性5. 如何保证数据一致性，事务消息如何实现

你可以把消息队列理解为一个使用队列来通信的组件。它的本质，就是个转发器，包含发消息、存消息、消费消息的过程。最简单的消息队列模型如下：

我们通常说的消息队列，简称MQ（Message Queue），它其实就指消息中间件，当前业界比较流行的开源消息中间件包括：RabbitMQ、RocketMQ、Kafka。

有时候面试官会换个角度问你，为什么使用消息队列。你可以回答以下这几点：

应用解耦
流量削峰
异步处理
消息通讯
远程调用

消息队列内置了高效的通信机制，可用于消息通讯。如实现点对点消息队列、聊天室等。

一个消息从生产者产生，到被消费者消费，主要经过这3个过程：

因此如何保证MQ不丢失消息，可以从这三个阶段阐述：

生产者保证不丢消息
存储端不丢消息
消费者不丢消息

生产端如何保证不丢消息呢？确保生产的消息能到达存储端。

如果是RocketMQ消息中间件，Producer生产者提供了三种发送消息的方式，分别是：

同步发送异步发送单向发送

生产者要想发消息时保证消息不丢失，可以：

采用同步方式发送，send消息方法返回成功状态，就表示消息正常到达了存储端Broker。如果send消息异常或者返回非成功状态，可以重试。可以使用事务消息，RocketMQ的事务消息机制就是为了保证零丢失来设计的 3.2 存储端不丢消息

确保消息持久化到磁盘。大家很容易想到就是刷盘机制。

同步刷盘: 生产者消息发过来时，只有持久化到磁盘，RocketMQ的存储端Broker才返回一个成功的ACK响应。会影响性能异步刷盘: 只要消息写入PageCache缓存，就返回一个成功的ACK响应。这样提高了MQ的性能，但是如果这时候机器断电了，就会丢失消息。

Broker一般是集群部署的，有master主节点和slave从节点。消息到Broker存储端，只有主节点和从节点都写入成功，才反馈成功的ack给生产者。这就是同步复制，它保证了消息不丢失，但是降低了系统的吞吐量。与之对应的就是异步复制，只要消息写入主节点成功，就返回成功的ack，它速度快，但是会有性能问题。

消费者执行完业务逻辑，再反馈会Broker说消费成功，这样才可以保证消费阶段不丢消息。

生产者发消息时，1个Topic只能对应1个Partition，一个 Consumer，内部单线程消费。

但是这样吞吐量太低，一般保证消息局部有序即可。在发消息的时候指定Partition Key，Kafka对其进行Hash计算，根据计算结果决定放入哪个Partition。这样Partition Key相同的消息会放在同一个Partition。然后多消费者单线程消费指定的Partition。

生产者产生消息，发送带MQ服务器MQ收到消息后，将消息持久化到存储系统。MQ服务器返回ACk到生产者。MQ服务器把消息push给消费者消费者消费完消息，响应ACKMQ服务器收到ACK，认为消息消费成功，即在存储中删除消息。

事务消息保证数据一致性问题

生产者产生消息，发送一条半事务消息到MQ服务器MQ收到消息后，将消息持久化到存储系统，这条消息的状态是待发送状态。MQ服务器返回ACK确认到生产者，此时MQ不会触发消息推送事件生产者执行本地事务如果本地事务执行成功，即commit执行结果到MQ服务器；如果执行失败，发送rollback。如果是正常的commit，MQ服务器更新消息状态为可发送；如果是rollback，即删除消息。如果消息状态更新为可发送，则MQ服务器会push消息给消费者。消费者消费完就回ACK。如果MQ服务器长时间没有收到生产者的commit或者rollback，它会反查生产者，然后根据查询到的结果执行最终状态。