rocketmq 学习 - 面试

高可用保证：
NameServer 集群化部署
Rocketmq 解决思路：Broker主从架构与多副本策略。
简单说：Broker 有master与slave 两种角色。master收到消息后同步给slave。这样slave broker 就有一模一样的副本数据！这样master出现故障。slave 还有一模一样的数据，同样对外提供服务。保证MQ的可靠性与可用性。

Rocketmq 如何支持高并发的呢？

假如一台高性能机器，mq支持十万+并发。rocketmq可以集群部署，部署多台。假如每台支持十万+的请求，我们只需要将请求均匀分散到多台机器上，保证每台请求QPS不超过10万即可。

数据路由，怎么知道访问哪个Broker？

所有的Broker都把自己注册到NameServer 上！ 这样NameServer知道集群有哪些Broker。知道所有的Broker信息！
如果NameServer集群化，Broker将自己注册到所有的NameServer上，达到高可用。假如一个NameServer挂了，其它NameServer同样存在所有broker信息
对于我们应用系统来讲，也会找NameServer要、获取路由信息，去查找对应的Broker信息。

系统如何从NameServer获取Broker信息

定时，每隔一段时间从NameServer拉取最新Broker集群信息。

心跳机制，NameServer如何知道Broker是否存活

30秒心跳机制 120s 故障感知机制

1. Broker 每30s 给所有的NameServer 发送心跳。告诉每个NameServer 他还活着。
2. NameServer 收到心跳包后，更新Broker 心跳时间。
3. 每隔10s NameServer 检测Broker 心跳时间。如果某个Broker 超过120s都未发送心跳。则可以认为Broker 已经挂掉。

Broker挂了，系统如何感知呢？

两种解决思路：

1. broker挂了，可以发送给其它broker。
2. 如果系统必须发送给那个broker。他slave机器有一个备份。等一会可以继续使用。是否考虑再等一等。

Master Broker 如何同步消息到Slave Broker 的？

Slave节点主动向Master节点拉取数据，PULL模式

Broker 节点是采取读写分离模式吗？

不是！ 消费者有可能从master节点拉取消息，也有可能从slave节点拉取消息。
消费者从master节点拉取消息后。master根据自身的负载情况与slave 节点同步情况，建议下一次从master节点拉取还是从slave节点拉取。

slave 节点挂了对系统有应用吗？

有影响的！ 但不大。消息写入都是走master 节点的。消息读取也是走master节点。只是有部分消息读取是走，slave节点。
只是slave节点挂了，全部的压力都打到master 节点上。