前面的文章分析了Rocketmq消息队列的常用功能原理，涉及到如下内容：
Rocketmq消息中间件实现了消息队列的基本功能，如消息发送，集群消费，广播消费，也实现了消息堆积，事务消息，定时消息，?顺序消息等高级功能。
Rocket常见问题?分析总结：
一、如何保证消息不重复消费?
?????在Rocketmq中每条消息都有一个唯一的key代表不同消息实体，Rocketmq本身并不保证消息不被重复消费，它通过重试机制保证消息至少被消费者消费一次，因此可能在网络抖动情况下出现消息重复投递的情况，如何达到消息不被重复消费呢？
这里介绍笔者工作中常用的两种方式：
1、消息消费记录表
?????消息业务id作为主键或者唯一id,每次消费前判断是否存在消费记录，可以尝试插入操作，如果已经存在则会报主键冲突（类似于redis的setNx指令效果）。存在则不消费，否则继续消费。
2、通过redis的setnx指令
?????Redis Setnx（SET?if?Not eXists）?命令在指定的 key 不存在时，为 key 设置指定的值。
这里保证key是消息的唯一标志。
二、消息堆积如何处理?
1、提高消费并行度?
?????同一个ConsumerGroup,通过增加 Consumer 实例数量来提高并行度（需要注意的是超过订阅队列数的 Consumer 实例无效）。可以通过加机器，或者在已有机器启动多个进程的方式。
???提高单个 Consumer 的消费并行线程（扩大消费者线程池，默认20个核心线程），通过修改参数 consumeThreadMin、consumeThreadMax实现。?
2、批量消费方式?
?????某些业务流程如果支持批量方式消费，则可以很大程度上提高消费吞吐量，例如订单扣款类应用，一次处理一个订单耗时 1 s，一次处理 10 个订单可能也只耗时 2 s，这样即可大幅度提高消费的吞吐量，通过`设置 consumer的?consumeMessageBatchMaxSize?参数`，默认是?1，即一次只消费一条消息，例如设置为 N，那么每次消费的消息数小于等于 N。?
3、跳过非重要消息?
?????过滤掉不重要的消息，追赶上生产者进度发生消息堆积时，如果消费速度一直追不上发送速度，如果业务对数据要求不高的话，可以选择丢弃不重要的消息。例如，当某个队列的消息数堆积到100000条以上，则尝试丢弃部分或全部消息，这样就可以快速追上发送消息的速度?。
如何定位具体哪个线程消费消息慢？
通过jstack 查看消费者线程状态，判断阻塞线程。
三、Rocketmq如何保证消息不丢失
消息丢失这个话题必须?在Rocketmq的各个组成角色的角度来分析。
1、?生产者自带重试功能
???????至多重试2次。
??????如果同步模式发送失败，则轮转到下一个Broker，如果异步模式发送失败，则只会在当前Broker进行重试。这个方法的总耗时时间不超过sendMsgTimeout设置的值，默认10s。
?????如果本身向broker发送消息产生超时异常，就不会再重试。?
2、broker高可用和高可靠?
主从同步机制?
brokerRole broker角色类型
ASYNC_MASTER, 异步同步主节点
SYNC_MASTER, 同步同步主节点?
SLAVE; 从节点?
DiskFlush 刷盘策略?
默认写入缓冲区，不会同步落盘，通过定时5s进行刷新落盘
SYNC_FLUSH, 同步刷盘，刷盘完成再返回给客户端，超时5s
ASYNC_FLUSH,异步刷盘，200ms刷新一次，性能高?
3、消费者
?????消费者消费消息时关闭自动提交ack,而是采用手动提交消息offset，消费者消费消息不成功，不返回CONSUME_SUCCESS，返回RECONSUME_LATER表示需要broker再次投递该消息。
生产者和broker保证消息不丢失，可能导致消息重复投递，因此消费者需要做幂等性处理。?
最后看下Rocket官网给出的Rocketmq和Kafka消息中间件的对比?：
学习了Rocketmq后发现Rocketmq确实是一个优秀的消息中间件,它不仅有阿里等大厂大流量的使用和历练，还拥有活跃的社区，最新的文档，不停的升级迭代，源码学习可以了解消息中间件的运行原理，对消息队列的实现机制更加掌握。
2020新的开始，祝大家新年快乐，2020继续学习新技术，一起继续进步?！?！