RocketMQ消息丢失的场景及其解决方案的学习笔记

我在秒杀项目中使用了RocketMQ实现了异步消息下单的操作，既然是发送异步消息就会存在消息丢失的情况，故对RocketMQ消息丢失的场景及其解决方案进行了学习。下面为我的一些学习笔记。

使用RocketMQ发送消息到消费消息大概会经过以下流程：

1. 生产者生产消息
2. RocketMQ接收消息并将消息写入内存缓存os cache中
3. RocketMQ将消息写入磁盘中
4. 消费者消费RocketMQ中的消息。

在这一套流程中主要可能在四个地方出现消息，即下图中的红字描述的情况：

场景一：

生产者发送消息的途中由于网络抖动，通信异常所导致消息丢失的情况

这里主要采用RocketMQ自带的事务型消息机制来解决此类问题，主要的流程为：

1. 生产者先发送half消息到RocketMQ中，这个half消息是不能被消费者消费的，如果half消息发送失败了则执行相应的回滚逻辑。
2. half消息发送成功之后，且RocketMQ返回成功响应，则执行生产者的核心链路
3. 如果生产者自己的核心链路执行失败，则回滚，并通知RocketMQ删除half消息
4. 如果生产者的核心链路执行成功，则通知RocketMQ commit half消息，让消费者可以消费这条数据

也就是说赋予了消息一个中间状态half，只有消息发送成功得到双方的确认才能够被消费。

场景二：

可以将os cache的异步刷盘策略改为同步刷盘

具体操作为：修改Broker的配置文件，将flushDiskType改为SYNC_FLUSH同步刷盘策略，默认的是ASYNC_FLUSH异步刷盘。

在同步刷盘模式下一旦刷盘成功，就一定保证消息已经持久化到磁盘中了。

场景三：

为了保证磁盘损坏不会丢失数据，我们需要对RocketMQ采用主从机制，集群部署，Leader中的数据在多个Follower中都存有备份，防止单点故障。

场景四：

采用同步消费消息的方式

//注册消息监听器处理消息
consumer.registerMessageListener(new MessageListenerConcurrently() {
   @Override
    public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context){ 		 						                        
        //对消息进行处理
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
    }
});

使用上述代码，RocketMQ在消费者中注册了一个监听器，当消费者获取到了消息，就会去回调这个监听器函数，去处理里面的消息当你的消息处理完毕之后，才会返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS

只有返回了CONSUME_SUCCESS，消费者才会告诉RocketMQ我已经消费完了，此时如果消费者宕机，消息已经处理完了，也就不会丢失消息了

如果消费者还没有返回CONSUME_SUCCESS时就宕机了，那么RocketMQ就会认为你这个消费者节点挂掉了，会自动故障转移，将消息交给消费者组的其他消费者去消费这个消息，保证消息不会丢失
整体的解决方案流程图为：

使用上述方案就能保证RocketMQ在生产和消费消息时实现零丢失，但是这同时也会对系统的性能即吞吐量造成较大影响，故应该针对具体业务场景具体分析。