rocketmq面试

broker主从复制机制

同步复制：
等Master和Slave均写成功后，才反馈给客户端写成功状态；
如果Master出故障， Slave上有全部的备份数据，容易恢复，但是同步复制会增大数据写入延迟，降低系统吞吐量。
异步复制：
只要Master写成功，即可反馈给客户端写成功状态。后面再通过异步的方式和slave同步。
较低的延迟和较高的吞吐量，如果master故障，有可能因为某些数据没有被写入slave，造成丢失。

复制流程分为两步，元数据同步、消息数据复制
元数据同步：Slave Broker 定时任务每隔 10 秒会同步元数据，包括主题，消费进度，延迟消费进度，消费者配置。
同步主题时, Slave Broker 向 Master Broker 发送 RPC 请求，返回数据后，首先加入本地缓存里，然后持久化到本地。

消息数据复制：
1、Master 启动监听指定端口
2、Slave 启动 HaClient 服务，和 Master 创建 TCP 链接
3、Slave 向 Master 上报存储进度
4、Master 接收进度，消息文件中检索该偏移量后的所有消息，并传输给 Slave
5、Slave 接收到数据后，将消息数据 append 到本地的消息存储。

Master和Slave之间是怎么同步数据的呢
通过raft协议
在broker收到消息后，会被标记为uncommitted状态
然后会把消息发送给所有的slave
slave在收到消息之后返回ack响应给master
master在收到超过半数的ack之后，把消息标记为committed
发送committed消息给所有slave，slave也修改状态为committed

工作流程

1、启动NameServer，NameServer启动后监听端口，等待Broker、Producer、Consumer连上来，相当于一个路由控制中心。
2、Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。
3、收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。
4、Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。
5、Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息。
Master支持读和写，Slave仅支持读，也就是 Producer只能和Master连接写入消息；Consumer可以连接 Master，也可以连接Slave来读取消息。

持久化机制（刷盘）

同步刷盘：在返回写成功状态时，消息已经被写入磁盘。具体流程是，消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘， 然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，返回消息写成功的状态。响应时间比异步多10%，用在对消息可靠性比较高的

异步刷盘：在返回写成功状态时，消息可能只是被写入了内存的PAGECACHE，写操作的返回快，吞吐量大；当内存里的消息量积累到一定程度时，统一触发写磁盘动作，快速写入。用在吞吐量比较高的

配置：Broker配置文件里的flushDiskType，SYNC_FLUSH（同步刷盘）、ASYNC_FLUSH（异步刷盘）

如何保证消息不丢失，保证消息的可用性/可靠性

producer：消息成功发送
同步发送，broker返回成功后，表示数据送到了

broker：消息持久化
消息持久化到commitLog
刷盘，同步刷盘和异步刷盘，将消息存储
master和slave的同步机制，同步双写可以保证在master宕机时，slave还可以有消息给consumer消费。

consumer：标记已经消费的消息offset
consumer中也保存了一个offset，用来表示消费成功却已经发回broker的消息下标，发回失败时也会定时重试，offset是持久化的。

消息存储结构

CommitLog：
消息主体与元数据的存储主体，文件默认大小是1G，CommitLog 存储的数据是在当前这个broker中的所有的topic的数据
consumerQueue：
只记录具体某个topic下的数据，一个topic下有多个consumerQueue，作为消费索引，它记录了指定topic的队列消息在CommitLog中的位置（物理位置偏移量offset

indexFile
indexes 里记录了 key的hash值，在commitLog中的偏移量，与 beginTimestamp的差值，下一个索引的值（记录key和offset的对应关系。

零拷贝

RocketMQ为什么速度快

是因为使用了顺序存储、Page Cache和异步刷盘。

我们在写入commitlog的时候是顺序写入的，这样比随机写入的性能就会提高很多

写入commitlog的时候并不是直接写入磁盘，而是先写入操作系统的PageCache

最后由操作系统异步将缓存中的数据刷到磁盘

如何保证顺序

顺序由producer发送到broker的消息队列是满足FIFO的，所以发送是顺序的，单个queue里的消息是顺序的。多个Queue同时消费是无法绝对保证消息的有序性的。所以，同一个topic，同一个queue，发消息的时候一个线程发送消息，消费的时候一个线程去消费一个queue里的消息。RocketMQ给我们提供了MessageQueueSelector接口，可以重写里面的接口，实现自己的算法，比如判断i%2==0，那就发送消息到queue1否则发送到queue2。