1. rocketmq的消息是如何存储的？
   1. 存储在commitlog里面，和kafka一样顺序读取。
2. rocketmq是否会在消息消费完成之后如何处理？
   1. 首先是肯定不会立刻物理删除，此外也没有逻辑删除的设计。
   2. 消息大小不定长，所以消息的清理是不可能以消息为单位进 行清理的，而是以commitlog 文件为单位进行清理的。否则会急剧下降清理效率，并实现逻辑复杂。
   3. 可以配置过期时间（默认72H），以及还有一些其他清理点。
3. offset的更新策略？
   1. 首先考虑性能问题，并不会是每消费完一个消息就上报一次，而是批量消费完合并上报一次，显然这里就有个问题，批量消费一部分后没完成offset上报consumer就挂掉了怎么办，实际上没有办法，只能其他等启动或者分配给其他consumer后重新消费这些消息，所以说用rocketmq一定要处理重复消费带来的问题，也就是需要幂等处理。
4. offset存哪里？
   1. kafka是存在zookeeper上的，每一个topic的维度，都会记录一个offset值，所以consumer挂了之后也是能保证消费位置的获取。和rocketmq一样，kafka也是支持批量消费后上报的，那就是也存在重复消费的问题。这里要注意下重复消费和重消费的区别，前者是组件存在的问题，后者是组件提供的能力。
   2. 而rocketmq的offset并没有和kafka一样存在协调者中，而是根据不同消费方式做了不同处理：
      1. 广播消费：该模式下，没有全局offset的概念，所以offset持久化存放在consumer本地的文件中，详见：org.apache.rocketmq.client.consumer.store.LocalFileOffsetStore#persistAll。consumer重启过程中会加载该文件。
      2. 集群消费：该模式下需要不同consumer共享offset，需要记录offset到远端，但rocketmq的设计是存放在broker中，详见：org.apache.rocketmq.client.consumer.store.RemoteBrokerOffsetStore#persistAll。在rebalance之后，该topic下新分配的consumer会拿到该offset继续消费。
5. 什么情况下触发rebalance？
   1. consumer group内的consumer节点变化之后，就会触发。