消息队列的应用场景

1. 应用解耦
2. 流量削峰

3. 异步处理

   应用解耦

   用户下单后，需要通知仓储服务减库存，会员服务加积分。在不引入MQ的时候，需要订单服务直接调用库存和会员服务。
   如果未来有更多的服务要接入，就需要再去下单那块写代码
   引入MQ后，订单服务仅需要向MQ发送一条消息即可，具体下游服务增加或减少都不需要订单服务操心

   流量削峰

   秒杀场景下，大量请求压过来，可以先暂时将这些请求信息放入MQ，应用服务器依据自己的能力慢慢的进行消费

   异步处理

   有些业务逻辑可能很耗时，此时可以将业务逻辑需要的入参放入MQ，之后通过接收MQ的消息去异步执行这块业务逻辑。实际开发中：电子发票开票

   RocketMQ如何保证消息不丢失的？

   生产者保证消息不丢

4. 同步发送方式：客户端接收成功状态可以保证消息发送成功，若未接收到，则有生产者有默认的3次重投机制

5. 异步发送方式：生产者会对发送失败的消息进行重试

6. oneway方式：无保障

   存储端不丢消息

   Broker接收到消息后会将消息进行刷盘操作，具体刷盘方式有：

7. 同步刷盘：当消息刷到磁盘后才返回ACK

8. 异步刷盘：当消息写入PageCache后就立即返回ACK，刷盘操作由操作系统自行判断执行时机

9. 集群模式下

   1. 同步Master：Master自己处理好，且收到Slave处理好的ACK后才返回ACK
   2. 异步Master：Master自己处理好，就返回ACK

      消费阶段不丢消息

      重试Topic

      RocketMQ如何保证消息顺序性

10. RocketMQ的一个Topic中会有多个MessageQueue

11. 同一个MessageQueue下消费消息是有序的，也称为局部有序，不同MessageQueue下消费不一定有序
12. 实现全局有序的方式是设置Topic的MessageQueue为1个即可
13. 可以根据局部有序的规则，通过业务key，将同一个业务的相关消息指定发送到同一个MessageQueue中。如将订单号作为key，订单号只要相同必定发往同一个MessageQueue。