（1）问：rocketMQ中，主要有哪些角色？
答：producer，consumer，broker
（2）问：rocketMQ中，主要有什么消费模式？
答：广播消费，集群消费
广播消费就是：每一个consumer都可以消费某条消息，哪怕在同一个组；
集群消费就是：一个group中的consumer平均分摊消费的消息；
（3）问：顺序消息有哪些？
答：顺序消息，普通顺序消息，严格顺序消息。
顺序消息：消费的顺序与发送消息的顺序一致，主要指局部有序，做法是，一类消息的producer单线程发送，且发送到一个队列中。
普通顺序消息：正常情况下，完全顺序。但是broker重启时，可能会顺序紊乱
严格顺序消息：任何情况下，完全顺序。但是这样的话，broker只要一台不可用，就集群不可用。可以用同步双写来进行优化，主机挂了用备机顶上。除了binlog以外，其他大多都可以允许短暂的无顺序。
（4）问：queue有长度限制吗？
答：没有。
rocketMQ中，所有消息都是持久化的。queue使用commit log的offset作为单元储存，一百年都不会溢出。所以认为长度无限。
（5）问：消息中间件可以解决哪些问题？什么时候使用消息中间件？
答：限流，削峰，解耦。
（6）问：消息中间件支持什么功能？
答：publish/subscribe是消息队列的基本模式；
message priority：使消息具有优先级，投递的时候会按照优先级进行投递。但是按照优先级排序开销太大了。所以可以根据优先级配置不同的根据优先级高低配置的队列，如此就可以模仿优先级了。一般优先级用着整数表示，当需要的优先级精度不高时，可以笼统分为高中低等层级，用topic予以划分，不同的优先级使用不同的topic。但是优先级精度高时，就不合适了。
（7）问：消息有序
答：支持消息有序，且可以严格保障消息有序
（8）问：持久化方式有哪些
答：1、持久化到数据库；2、持久化到k-v存储；3、文件记录；4、持久化镜像
（9）问：关于消息可靠性
答：硬件资源没大问题的话，可以不丢失或少丢失数据，主要看是同步还是异步。
硬件问题的话，最好采用同步双写避免单点故障。
（10）问：至少消费一次是什么意思？
答：指的是每个消息必须投递一次，consumer先pull消息到本地，消费完成后，才向服务器返回 ack，如果没有消费一定不会 ack 消息
（11）问：低延迟消息指的什么？
答：消息不堆积时，没有延迟，到达broker就能立刻到达consumer。pull长轮训方式，消息实时性很高。
（12）问：Exactly Only Once如何实现?
答：发送消息和消费消息的阶段都不允许有重复。
但是为了保证这样，分布式需要巨大的开销，因此rocketMQ不保证严格的去重。
（13）问：broker的buffer满了怎么办？
答：Broker 的 Buffer 通常指的是 Broker 中一个队列的内存 Buffer 大小，这类 Buffer 通常大小有限，如果 Buffer 满了以后怎么办？
想想一下线程池的拒绝策略。类似fifo，lifo，priority等等
RocketMQ 没有内存 Buffer 概念，RocketMQ 的队列都是持久化磁盘，数据定期清除。
（14）问：回溯消费是什么？
答：回溯消费指的是consumer已经消费成功的消息，由于业务需求，需要重新消费消息。
（15）问：什么是消息堆积？
答：为了蓄洪泄洪，所以rocketMQ有一定的消息堆积能力，消息堆积主要分为以下两种情况：1、堆积在内存buffer里，所以一旦超过容量，选择拒绝策略；2、堆积在持久化系统中，这时候消费能力主要看吞吐量。
（16）问：rocketMQ支持分布式事务嘛？
答：当然。分布式事务基于两阶段提交。rocketMQ可以支持两阶段提交。系统A发送消息给中间件，中间件存储消息，此时消息对系统B不可见。然后系统A执行本地操作，回调结果给中间件。然后中间件的消息对系统B可见，B拉取消息完成B系统的消费，然后更新系统B的本地操作，之后回馈broker。如果失败，broker会转入失败队列，然后重新消费。
（17）问：rocketMQ是如何物理部署的？
答：name server,producer,consumer,broker。都可以进行集群部署。
并且，broker管理所有topic，并将topic注册到name server当中，集群中每个 Broker 与 Name Server 集群中的所有节点建立长连接。
然后producer与集群中的一台name server建立长链接（name server是完全同步的，每一台都一样。），获取记录的topic路由信息，然后与提供topic服务的broker集群中的master建立长连接，定时发送心跳。consumer也会与集群中的一台name server建立长连接，获取topic路由信息，然后与提供topic服务的master，slave建立长连接，定时发送心跳。
（18）问：rokcetMQ是怎么做存储的？
答：它选用的储存系统是文件系统，树形结构。消息记录选用commit log。queue使用commit log的offset作为消息的指代。
持久化方式：
（1）所有数据单独存储到一个 Commit Log，完全顺序写，随机读。
（2）对最终用户展现的队列实际只存储消息在 Commit Log 的位置信息，并且串行方式刷盘。
这种方式，可以让queue队列无限长，单个队列轻量化。对磁盘访问顺序化。但是，先读queue再读commitlog会增加开销。
（19）问：你刚才提到了串行方式刷盘，那你了解刷盘策略嘛？
答：两种刷盘策略。串行/异步
异步刷盘：写入缓存后就返回，然后异步刷入磁盘。
同步刷盘：写入缓存，并输入磁盘后，才返回。
（20）问：当网络堵塞，消息堆积，除了写入io还有读取io，万一读取磁盘速度落后，会不会出现内存溢出？
答：不会。操作系统调用NIO的方式去对内存进行管理。因为会有对于页的舍弃策略。如果内存不足，LRU会丢弃干净页（干净页就是磁盘和内存信息一致，没有被更改的页，就是把与当前要写入的内容无关的缓存剔除，缓存当前需要写入的内容，也就是放弃读来保护写），腾出内存，脏页里面有更新的信息，是最新数据，不可以随意丢弃。如果干净页不足，则刷脏页数据到磁盘，落盘了他就成为了干净页。
（21）问：消息查询有哪些方式？
答：message ID 、message Key
（22）问：消息过滤方式是什么？
答：是在订阅的时候过滤信息的。
通过在 Broker 端进行 Message Tag 比对，先遍历 Consume Queue，message tag hashcode去比对实际broker中的message tag做hash处理后的hashcode。
如果比对成功，即Consumer 收到过滤后的消息后，会在broker端继续进行比对，但是比对的是实际的message tag。
(1). Message Tag 存储 Hashcode，是为了在 Consume Queue 定长方式存储，节约空间。
(2). 过滤过程中不会访问 Commit Log 数据，可以保证堆积情况下也能高效过滤。
(3). 即使存在 Hash 冲突，也可以在 Consumer 端进行修正，保证万无一失。
（23）问：rocketMQ可以实现顺序消息吗？怎么实现的？
答：将要顺序执行的消息串行发送到一个队列中，并且串行执行即可。
（24）问：如何解决重复消息？
答：重复消息的根本原因是网络波动，但这个看天意。所以我们要么努力发送端无重复，也就是保障网络波动小。要么保障消费幂等性。
（25）问：过滤信息是怎么做的？
答：filterServer和broker部署在一起，利用回环网卡调用，减少网络传输的开销。可以满足多种条件的过滤。