版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
1.RocketMQ如何避免重复消费？
RocketMQ本身不保证消息重复消费，如果业务有要求不能重复消费，需要在自身的业务处理，常见的操作有两种;
- 接口幂等，消费端业务消息保持幂等性，例如redis的setNx()命令，当然要注意设置key的超时时间，以及key的唯一性。
- redis的Incr命令，确定消息的唯一值，在set之前先判断值是否存在，同时也是需要注意超时时间。
2.RocketMQ如何保证消息的可靠性传输，以及如何处理丢失？
- produce端：1.不采用oneway发送，使用同步或者异步方式发送，做好重试，但是重试的MessageKey必须唯一；2.投递的日志需要保存，关键字段，投递时间，重试次数，请求体，响应体。
- broker端：1.双主双从架构，NamerServer需要多节点；2.同步双写，异步刷盘（同步刷盘则可靠性更高，但性能稍差，可根据业务选择）。
- consumer端：1.消息消费日志必须保留，即消息的元数据和数据体；2.消费端务必做好幂等处理。
- 投递到broker端后：1.机器断电重启：异步刷盘，消息丢失；同步刷盘，消息不丢失；2.硬件故障：可能存在丢失，看队列架构。
3.消息发生大量堆积怎么处理？
问题描述：消息堆积了10个小时，有几千万条数据堆积，如何处理？
问题描述：修复consumer，然后慢慢消费，需要几个小时才能完成，新的消息怎么办?
处理办法：临时topic队列扩容，并提高消费能力，但是如果增加consumer数量，堆积的topic里面的message queue数量固定，过的的consumer不能分配到messge queue。临时编写处理分发程序，从旧的topic快递读取到临时的topic中，新的topic的queue数量扩容多倍，然后再启动，更多的consumer进行临时的新topic里消费。
4.RocketMQ高性能的原因分析
MQ架构配置：
- 顺序写，随机读，零拷贝；
- 同步刷盘，异步刷盘，可根据选择配置；
- 同步复制异步复制，可根据选择配置（推进同步双写，异步刷盘）；
发送端高可用：
- 双主双从架构：创建多个topic的时候，MessageQueue创建在多个broker上，即相同的broker名称，不同的brokerid(即主从模式)，当一个master不可用时，组内其他的master任然可用。但机器资源不足时，需要手工把slaver转成master，目前不支持自动转换，需要借助shell脚本。
消费端高可用：
- 主从架构，Broker角色，master提供读写，slaver提供读；
- Consumser不用配置，当master不可用或者繁忙的时候，Consumer会自动切换到Slaver节点进行读取；
提供消息的消费能力：
- 并行消费：增加多个节点；增加多个Consumer的并行度，修改consuemrThreadMin和consumerThreadMax；批量消费，设置Consumer的consumerMessageMaxSize，默认是1，如果为N,则消息多的时候，每次收到的消息为N。
- 选择linux Ext4文件系统，Ext4文件删除1G大小的文件毫升小于50ms,而Ext3则要1s,删除文件磁盘压力大时，会导致IO超时。