首先列出mq产品各方面对比如下：
选择rocketmq的原因：
性能是首要考虑的要素。开发语言是java，主要是为了方便二次开发。对于高并发的业务场景是需要支持分布式架构的设计。功能全面，由于不同的业务场景，可能会用到顺序消息、事务消息等。 1 工作流程：
- 启动NameServer,NameServer启动后开始监听端口，等待broker，producer，consumer连接启动broker时，broker会和所有的NameServer建立并保持长链接，然后每隔30s向NameServer定时发送心跳包发送消息前，可以先创建Topic，创建Topic时需要指定该topic要存储在哪些broker上，同时也会将topic和broker的关系写入到NameServer，不过这步并不是必需的，也可以在发送消息时自动创建topic
手动创建Topic有两种模式：
1）集群模式：该模式下创建的Topic在该集群中，所有Broker的Queue数量是相同的。
2）Broker模式：该模式下创建的Topic在该集群中，每个Broker的Queue数量可以不同。
自动创建Topic时，默认采用Broker模式，会为每个Broker默认创建4个Queue
- producer发送消息，启动时与NameServer集群中的其中一台建立长链接，并从NameServer中获取路由信息，即当前发送的Topic和Queue与Broker的地址(IP+Port)的映射关系。然后根据算法策略从队列选择一个Queue，与队列所在的broker建立长链接从而向broker发送消息。在获取到路由信息后，Producer会首先将路由信息缓存到本地，再每隔30s从NameServer更新一个路由信息。、Consumer和Producer类似。和其中一个NameServer建立长链接，获取其所订阅的Topic信息，然后根据算法策略从路由信息中获取到所要消费的Queue，然后和broker建立长链接，开始消费其中的消息。Consumer在获取到路由信息后，也会每隔30s从NameServer更新一次路由信息，不过和Producer不同的是，Consumer还会向Broker发送心跳，以确保Broker的存活状态。
同步复制：消息写入到Master后，Master会等待Salve同步数据成功后才向Producer返回ACK异步复制：消息写入到Master后，Master会立即向Producer返回成功ACK，无需等待Salve同步数据成功
异步复制策略可以降低系统的写入延迟，RT变小，提高系统的吞吐量
刷盘策略: 指Broker中的消息数据从内存持久化到磁盘的落盘方式，分为同步刷盘和异步刷盘同步刷盘：当消息持久化到Broker的磁盘后才是消息写入成功异步刷盘：当消息写入到Broker的内存后即表示消息写入成功，无序等待消息持久化到磁盘
概念延伸
1）异步刷盘策略会降低系统写入延迟，RT变小，提高系统的吞吐量
2）消息写入到Broker的内存，一般是写入到PageCache
3）异步刷盘策略，消息会写入到PageCache后立刻返回成功ACK，但并不会立刻做落盘操作，而是当PageCache达到一定量时会自动进行落盘
是因为使用了顺序存储、Page Cache和异步刷盘。我们在写入commitlog的时候是顺序写入的，这样比随机写入的性能就会提高很多，写入commitlog的时候并不是直接写入磁盘，而是先写入操作系统的PageCache最后由操作系统异步将缓存中的数据刷到磁盘 4 消费者消费失败的问题，一直消费失败导致消息积压
因为考虑到消费者消费一直出错的问题，从以下几个角度来考虑：
（1）消费者出错，肯定是程序或者其他问题导致的，如果容易修复，先把问题修复，让consumer恢复正常消费
（1）如果时间来不及处理很麻烦，做转发处理，写一个临时的consumer消费方案，先把消息消费，然后再转发到一个新的topic和MQ资源，这个新的topic的机器资源单独申请，要能承载住当前积压的消息，处理完积压数据后，修复consumer，去消费新的MQ和现有的MQ数据，新MQ消费完成后恢复原状
5 异步发送，消息可靠性怎么保证消息丢失可能发生在生产者发送消息、MQ本身丢失消息、消费者丢失消息3个方面。
生产者丢失生产者丢失消息的可能点在于程序发送失败抛异常了没有重试处理，或者发送的过程成功但是网络异常MQ没收到，消息就丢失了。
由于同步发送的一般不会出现这样使用方式，所以我们就不考虑同步发送的问题，我们基于异步发送的场景来说。
异步发送分为两个方式：异步有回调和异步无回调，无回调的方式，生产者发送完后不管结果可能就会造成消息丢失，而通过异步发送+回调通知+本地消息表的形式我们就可以做出一个解决方案。以下单的场景举例。
下单后先保存本地数据和MQ消息表，这时候消息的状态是发送中，如果本地事务失败，那么下单失败，事务回滚。
下单成功，直接返回客户端成功，异步发送MQ消息
MQ回调通知消息发送结果，对应更新数据库MQ发送状态
JOB轮询超过一定时间（时间根据业务配置）还未发送成功的消息去重试
在监控平台配置或者JOB程序处理超过一定次数一直发送不成功的消息，告警，人工介入。一般而言，对于大部分场景来说异步回调的形式就可以了，只有那种需要完全保证不能丢失消息的场景我们做一套完整的解决方案。
MQ丢失如果生产者保证消息发送到MQ，而MQ收到消息后还在内存中，这时候宕机了又没来得及同步给从节点，就有可能导致消息丢失。
RocketMQ分为同步刷盘和异步刷盘两种方式，默认的是异步刷盘，就有可能导致消息还未刷到硬盘上就丢失了，可以通过设置为同步刷盘的方式来保证消息可靠性，这样即使MQ挂了，恢复的时候也可以从磁盘中去恢复消息。
虽然可以通过配置的方式来达到MQ本身高可用的目的，但是都对性能有损耗，怎样配置需要根据业务做出权衡。
消费者丢失消费者丢失消息的场景：消费者刚收到消息，此时服务器宕机，MQ认为消费者已经消费，不会重复发送消息，造成消息丢失。
RocketMQ默认是需要消费者回复ack确认，而kafka需要手动开启配置关闭自动offset。消费方不返回ack确认，重发的机制根据MQ类型的不同发送时间间隔、次数都不相同，如果重试超过次数之后会进入死信队列，需要手工来处理了。
6 如何保证消息的顺序性多个queue只能保证单个queue里的顺序，queue是典型的FIFO，天然顺序。多个queue同时消费是无法绝对保证消息的有序性的。
所以总结如下：一个Topic，同一个QUEUE，发消息的时候一个线程去发送消息，消费的时候 一个线程去消费一个queue里的消息。
Rocket MQ给提供了MessageQueueSelector接口，可以自己重写里面的接口，通过业务需要发送到指定的queue队列
RocketMQ没有真正意义的push，都是pull，虽然有push类，但实际底层实现采用的是长轮询机制，即拉取方式
broker端属性 longPollingEnable 标记是否开启长轮询。默认开启
追问：为什么要主动拉取消息而不使用事件监听方式？
事件驱动方式是建立好长连接，由事件（发送数据）的方式来实时推送。
如果broker主动推送消息的话有可能push速度快，消费速度慢的情况，那么就会造成消息在consumer端堆积过多，同时又不能被其他consumer消费的情况。而pull的方式可以根据当前自身情况来pull，不会造成过多的压力而造成瓶颈。所以采取了pull的方式。
8 broker处理拉取请求- Consumer首次请求BrokerBroker中是否有符合条件的消息，有的话响应Consumer，等待下次Consumer的请求；没有的话挂起consumer的请求，即不断开连接，也不返回数据使用consumer的offset， DefaultMessageStore#ReputMessageService#run方法每隔1ms检查commitLog中是否有新消息，有的话写入到pullRequestTable当有新消息的时候返回请求PullRequestHoldService 来Hold连接，每个5s执行一次检查pullRequestTable有没有消息，有的话立即推送
通过Topic在多Broker中分布式存储实现。
producer端，默认策略是随机选择：
producer维护一个index，每次取节点会自增，index向所有broker个数取余，自带容错策略
我们也可以自主的实现：发送端指定message queue发送消息到相应的broker，来达到写入时的负载均衡。提升写入吞吐量，但是当多个producer同时向一个broker写入数据的时候，性能会下降。
消息分布在多broker中，为负载消费做准备
consumer端
采用的是平均分配算法来进行负载均衡。
- queue个数大于Consumer个数， 那么Consumer会平均分配queue。会有多个consumer消费多个queue的情况queue个数小于Consumer个数，那么会有Consumer闲置，就是浪费掉了，其余Consumer平均分配到queue上。一个queue只会被同一个groop下的一个consumer消费
其他负载均衡算法：
平均分配策略(默认)(AllocateMessageQueueAveragely)：是前面讲的默认方式环形分配策略(AllocateMessageQueueAveragelyByCircle)：每个消费者依次消费一个partition，环状。手动配置分配策略(AllocateMessageQueueByConfig)：是通过配置的方式一致性哈希分配策略(AllocateMessageQueueConsistentHash)：一致性hash算法靠近机房策略(AllocateMachineRoomNearby)：就近元则，离的近的消费 10 RocketMQ在分布式事务支持的底层原理
你们用的是RocketMQ?RocketMQ很大的一个特点是对分布式事务的支持，你说说他在分布式事务支持这块机制的底层原理?
分布式系统中的事务可以使用TCC（Try、/confirm/i、Cancel）、2pc来解决分布式系统中的消息原子性
RocketMQ 4.3+提供分布事务功能，通过 RocketMQ 事务消息能达到分布式事务的最终一致
RocketMQ实现方式：
**Half Message：**预处理消息，当broker收到此类消息后，会存储到RMQ_SYS_TRANS_HALF_TOPIC的消息消费队列中
**检查事务状态：**Broker会开启一个定时任务，消费RMQ_SYS_TRANS_HALF_TOPIC队列中的消息，每次执行任务会向消息发送者确认事务执行状态（提交、回滚、未知），如果是未知，Broker会定时去回调在重新检查。
**超时：**如果超过回查次数，默认回滚消息。
也就是他并未真正进入Topic的queue，而是用了临时queue来放所谓的half message，等提交事务后才会真正的将half message转移到topic下的queue。
11 mq一些时间和次数上的规则：
消息在消费失败后会进入重试队列，16次（默认16次）才会进入死信队列 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
Broker每隔30秒（此时间无法更改）向所有nameserver发送心跳，心跳包含了自身的topic配置信息。
nameserver每隔10秒钟（此时间无法更改），扫描所有还存活的broker连接，若某个连接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间无法更改）没有发送心跳数据，则断开连接。
同步双写保证消息不会丢失，如果5s内未完成消息复制，则给生产者Producer返回结果：数据同步到Slave服务器超时
