悟已往之不谏，知来者之可追

消费进度如何管理的？老消费者组继续消费的管理方式新消费者组初始消费的管理方式解决建议总结

消息同步策略殊途同归同步基于offset而不是消息本身刷盘策略

所谓Rebalance到底在解决什么问题Rebalance具体是如何决定分配的数量的Rebalance是怎么对多Topic做分配Rebalance什么时候触发Rebalance可能会带来消息的重复消费

通讯协议Header datacodelanguageversionopaqueflagremarkextFields

消费完后的消息去哪里了？什么时候清理物理消息文件？这样设计带来的好处跳过历史消息的处理

保证消费成功启动的时候从哪里消费消息ACK机制Ack卡进度解决方案

ClientConfignamesrvAddrinstanceNameclientIPclientCallbackExecutorThreadspollNameServerIntervalheartbeatBrokerIntervalpersistConsumerOffsetIntervalvipChannelEnabledDefaultMQProducerproducerGroupcreateTopicKeydefaultTopicQueueNumssendMsgTimeout

组件总览Name ServerBrokerFilter Server（可选）Consumer/Producer

Broker端水平扩展Broker负载均衡commit logProducer负载均衡Consumer负载均衡集群模式广播模式

角色ProducerConsumerPushConsumerPullConsumer概念术语Producer GroupConsumer GroupTopicTagMessage QueueOffsetConsumer Offset集群消费广播消费顺序消息普通顺序消息严格顺序消息

生产端提供了一个接口 MessageQueueSelector如果扩容了怎么保证顺序消费？顺序消息，如果某条失败了怎么办？会不会一直阻塞？

概览消息发送异常时重复发送消费消息抛出异常消费者提交offset失败服务端持久化offset失败主从同步offset失败重平衡清理长时间消费的消息总结

核心概念消息诞生与发送路由表队列的选择其它特殊情况处理发送异常处理消息过大的处理消息存储如何保证高性能读写传统IO读写方式零拷贝mmap()sendfile()CommitLog刷盘机制异步刷盘同步刷盘高可用主从同步模式Dledger模式消息消费消费的两种模式集群模式广播模式ConsumeQueueRocketMQ如何实现消息的顺序性消息清理消息的一生总结消息发送消息存储高可用消息消费消息清理

1，事务消息代码实现2，顺序消息代码实现3，消息过滤代码实现4，延时消息代码实现

事务消息就是MQ提供的类似XA的分布式事务能力，通过事务消息可以达到分布式事务的最终一致性。半事务消息就是MQ收到了生产者的消息，但是没有收到二次确认，不能投递的消息。生产者先发送一条半事务消息到MQMQ收到消息后返回ack确认生产者开始执行本地事务如果事务执行成功发送commit到MQ，失败发送rollback如果MQ长时间未收到生产者的二次确认commit或者rollback，MQ对生产者发起消息回查生产者查询事务执行最终状态根据查询事务状态再次提交二次确认。

问题如果让你写一个消息队列，该如何进行架构设计啊？说一下你的思路。分析其实聊到这个问题，一般要考察两块：你有没有对某一个消息队列做过较为深入的原理的了解，或者从整体了解把握住一个消息队列的架构原理。看看你的设计能力，给你一个常见的系统，就是消息队列系统，看看你能不能从全局把握一下整体架构设计，给出一些关键点出来。说实话，问类似问题的时候，大部分人基本都会蒙，因为平时从来没有思考过类似的问题，大多数人就是平时埋头用，从来不去思考背后的一些东西。类似的问题，比如，如果让你来设计一个 Spring 框

问题如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？分析你看这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了；或者消费的速度极其慢。接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？或者是这整个就积压了几个小时，你这个时候怎么办？或者是你积压的时间太长了，导致比如 RabbitMQ 设置了消息过期时间后就没了怎么办？所以就这事儿，其实线上挺常见的，一般不出，一出就是大 case。一般常见于

如何保证消息的顺序性？分析其实这个也是用 MQ 的时候必问的话题，第一看看你了不了解顺序这个事儿？第二看看你有没有办法保证消息是有顺序的？这是生产系统中常见的问题。剖析我举个例子，我们以前做过一个 mysql binlog 同步的系统，压力还是非常大的，日同步数据要达到上亿，就是说数据从一个 mysql 库原封不动地同步到另一个 mysql 库里面去（mysql -> mysql）。常见的一点在于说比如大数据 team，就需要同步一个 mysql 库过来，对公司的业务系统的数据做各种复杂的操作

问题如何保证消息的可靠性传输？或者说，如何处理消息丢失的问题？分析这个是肯定的，用 MQ 有个基本原则，就是数据不能多一条，也不能少一条，不能多，就是前面说的重复消费和幂等性问题。不能少，就是说这数据别搞丢了。那这个问题你必须得考虑一下。如果说你这个是用 MQ 来传递非常核心的消息，比如说计费、扣费的一些消息，那必须确保这个 MQ 传递过程中绝对不会把计费消息给弄丢。剖析数据的丢失问题，可能出现在生产者、MQ、消费者中，咱们从 RabbitMQ 和 Kafka 分别来分析一下吧。RabbitM

问题如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？分析其实这是很常见的一个问题，这俩问题基本可以连起来问。既然是消费消息，那肯定要考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？这个是 MQ 领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性，这个是你架构里要考虑的一个问题。剖析回答这个问题，首先你别听到重复消息这个事儿，就一无所知吧，你先大概说一说可能会有哪些重复消费的问题。首先，比如 RabbitMQ、RocketMQ、Kafka，都有可

背景如果有人问到你 MQ 的知识，高可用是必问的。上一讲提到，MQ 会导致系统可用性降低。所以只要你用了 MQ，接下来问的一些要点肯定就是围绕着 MQ 的那些缺点怎么来解决了。要是你傻乎乎的就干用了一个 MQ，各种问题从来没考虑过，那你就杯具了，面试官对你的感觉就是，只会简单使用一些技术，没任何思考，马上对你的印象就不太好了。这样的同学招进来要是做个 20k 薪资以内的普通小弟还凑合，要是做薪资 20k+ 的高工，那就惨了，让你设计个系统，里面肯定一堆坑，出了事故公司受损失，团队一起背锅。剖析这个问

特性ActiveMQRabbitMQRocketMQKafka单机吞吐量万级，比 RocketMQ、Kafka 低一个数量级同 ActiveMQ10 万级，支撑高吞吐10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景topic 数量对吞吐量的影响topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topictopic 从几十到几百个时候，吞吐量会大幅度下降，...

问题为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？分析第一，你知不知道你们系统里为什么要用消息队列这个东西？不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头

现场还原消费端实现了MessageListenerConcurrently监听接口，然后实现了consumeMessage这个方法。此方法中，我开了线程池去执行消费消息的逻辑，但是走到一行打印日志的代码时候，突然不执行了。然后就没了，也没有报任何异常，下面的其他逻辑也没有执行。我怀疑是线程挂了。排查–追踪线程首先我排查下面的逻辑是否有问题， 发现没问题后，多打印了几个我觉得一定会打印的日志。结果发现，还是没有打印我觉得一定会打的日志。其次，我开始追踪这个线程。通过jps快速找到pid，jst

报错org.apache.rocketmq.client.exception.MQClientException: The consumer group[PushConsumer] has been created before, specify another name please.See http://rocketmq.apache.org/docs/faq/ for further d...

org.apache.rocketmq.client.exception.MQClientException: The specified topic[182.16.226.45] contains illegal characters, allowing only ^[%|a-zA-Z0-9_-]+$For more information, please visit the url, htt...