一、RocketMQ发送oneway消息和使用场景，多种发送模式对比：
发送方式    发送TPS         发送结果反馈         可靠性
同步发送    快             有              不丢失
异步发送    快             有              不丢失
单向发送    最快        无              可能丢失



二、什么是顺序消息？
消息的生产和消费顺序一致。

局部顺序：只要保证一组消息被顺序消费即可(RocketMQ使用)；性能要求高的和电商系统中常用。

顺序发布：对于指定的一个 Topic，客户端将按照一定的先后顺序发送消息。
顺序消费：对于指定的一个 Topic，按照一定的先后顺序接收消息，即先发送的消息一定会先被客户端接收到。

【注】：
顺序消息暂不支持广播模式。
顺序消息不支持异步发送方式，否则将无法严格保证顺序。



三、集群模式下消费端消费消息流程
Topic下队列的奇偶数会影响Customer个数里面的消费数量；
举例：
如果是4个队列，8个消息，4个节点则会各消费2条，如果不对等，则负载均衡会分配不均，
如果consumer实例的数量比message queue的总数量还多的话，多出来的consumer实例将无法分到queue，也就无法消费到消息，
也就无法起到分摊负载的作用，所以需要控制让queue的总数量大于等于consumer的数量。

集群模式(默认)：
Consumer实例平均分摊消费生产者发送的消息
举例：订单消息，一般是只被消费一次

广播模式：
广播模式下消费消息：投递到Broker的消息会被每个Consumer进行消费，一条消息被多个Consumer消费，广播消费中ConsumerGroup暂时无用
举例：群公告，每个人都需要消费这个消息



四、RocketMQ里面的Tag作用和消息过滤原理
一个Message只有一个Tag，tag是二级分类；
过滤分为Broker端和Consumer端过滤。
【注】：
消费者订阅关系要一致，不然会消费混乱，甚至消息丢失
订阅关系一致：订阅关系由 Topic和 Tag 组成，同一个 group name，订阅的 topic和tag 必须是一样的。



五、Push和Pull优缺点分析
Push：
实时性高；但增加服务端负载，消费端能力不同，如果Push推送过快，消费端会出现很多问题

Pull：
消费者从Server端拉取消息，主动权在消费者端，可控性好；
但间隔时间不好设置，间隔太短，则空请求，浪费资源；间隔时间太长，则消息不能及时处理

长轮询：
Client请求Server端也就是Broker的时候， Broker会保持当前连接一段时间，默认是15s，
如果这段时间内有消息到达，则立刻返回给Consumer，没消息的话 超过15s，则返回空，再进行重新请求；
主动权在Consumer中，Broker即使有大量的消息 也不会主动推送给Consumer， 
缺点：服务端需要保持Consumer的请求，会占用资源，需要客户端连接数可控 否则会一堆连接




六、什么是offset？
MessageQueue是无限长的数组，一条消息进来下标就会涨1，下标就是offset，
消息在某个MessageQueue里的位置，通过offset的值可以定位到这条消息，或者指示Consumer从这条消息开始向后处理
MessageQueue中的maxOffset表示消息的最大offset, maxOffset并不是最新的那条消息的offset，
而是最新消息的offset+1，minOffset则是现存在的最小offset。

有什么用？
主要是记录消息的偏移量，有多个消费者进行消费
集群模式下采用RemoteBrokerOffsetStore, broker控制offset的值
广播模式下采用LocalFileOffsetStore, 消费端存储



七、什么是分布式事务？
分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，
这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务。



八、RokcetMQ分布式事务消息的总体架构：
RocketMQ事务消息：
RocketMQ 提供分布式事务功能，通过 RocketMQ 事务消息能达到分布式事务的最终一致。

(1)、半消息Half Message:
暂不能投递的消息(暂不能消费)，Producer已经将消息成功发送到了Broker端，但是服务端未收到生产者对该消息的二次确认，
此时该消息被标记成"暂不能投递"状态，处于该种状态下的消息即半消息。

(2)、消息回查:
由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列 RocketMQ 服务端通过扫描发现某条消息长期处于"半消息"时，
需要主动向消息生产者询问该消息的最终状态(Commit 或是 Rollback)，该过程即消息回查。

(3)、RocketMQ事务消息的状态:
COMMIT_MESSAGE:   提交事务消息，消费者可以消费此消息
ROLLBACK_MESSAGE：回滚事务消息，消息会在broker中删除，消费者不能消费
UNKNOW：          Broker需要回查确认消息的状态




九、消息队列面试专题
1、讲解为什么使用消息队列？
异步，解耦，削峰
缺点：
系统可用性越低：外部依赖越多，依赖越多，出问题风险越大
系统复杂性提高：需要考虑多种场景，比如消息重复消费，消息丢失
需要更多的机器和人力: 消息队列一般集群部署，而且需要运维和监控

2、消息队列怎么避免重复消费？
RocketMQ不保证消息不重复，如果你的业务需要保证严格的不重复消息，需要你自己在业务端去重。
(1)、接口幂等性保障 ，消费端处理业务消息要保持幂等性。
(2)、Redis数据库去重，某个字段使用Message的key做唯一索引。

3、如何保证消息的可靠性，处理消息丢失的问题？
(1)、producer端
不采用oneway发送，使用同步或者异步方式发送，做好重试，但是重试的Message key必须唯一
投递的日志需要保存，关键字段，投递时间、投递状态、重试次数、请求体、响应体

(2)、broker端
双主双从架构，NameServer需要多节点
同步双写、异步刷盘 (同步刷盘则可靠性更高，但是性能差点，根据业务选择)

(3)、consumer端
消息消费务必保留日志，即消息的元数据和消息体
消费端务必做好幂等性处理

(4)、投递到broker端后
机器断电重启：异步刷盘，消息可能丢失；同步刷盘消息则不丢失
硬件故障：    可能存在丢失，看队列架构

4、消息大量堆积在broker里面，应该怎么处理？
(1)、临时topic队列扩容，并提高消费者能力，但是如果增加Consumer数量，
但是堆积的topic里面的message queue数量固定，过多的consumer不能分配到message queue
(2)、编写临时处理分发程序，从旧topic快速读取到临时新topic中，
新topic的queue数量扩容多倍，然后再启动更多consumer进行在临时新的topic里消费