RocketMQ系列(七)：主从同步

Posted 2023-03-14

参考技术A 先引几个问题

rocketMq的主从不是传统意义上的主从，他不具备主从切换，也就是说，从永远不会变成主。当主节点宕机后，从不会接管消息发送、消息存储，只提供消息的读取。

也就是说，生产者无法发消息了，消费者还可以继续接收队列中未消费的消息。

所有发消息的请求，都是主来处理的。主收到请求后，存在自己的commitLog中，然后，等着slave的offset拉取请求

那client消息拉取，是从master拉，还是从slave拉呢

来，看源码

1、本次拉取的数据量。master的总offset 减 请求的offset
2、物理内存的百分比。

40 除 100 就是0.4 再乘总内存大小。
所以 memory的值为 物理内存的40%

3、如果 本次拉取的数据量 大于 物理内存的40%。 那么下一次从slave拉取。防止master处理不过来。

也就是说，只有
1、master挂了
2、本次拉取的数据量大于物理内存的40%。
这两种情况，会用到slave。其余时候，slave就在那候着，master出事上，不出事就一直候着。

首先master挂了。消息就写不了了，也就是client不能发送消息了。消息只能从slave读。

offset存在slave的

中

很显然，从master拉。master起来后，slave就又开始候着了。

1、最新的offset存在slave上了。master怎么知道最新的offset。
2、master起来后，slave的定时任务起来了，他找master要group的offset，这个时候master的offset是过期的，slave收到后跟自己比，发现是过期的，丢弃。直到拿到的不是过期的，那master怎么更新自己的offset呢。

client在内存中保存着最新的offset。当以这个offset去master拉消息的时候，master就会发现自己的offset过期了，会用这个offset更新自己的offset。然后返回给client这个offset到自己commitLog最大offset之间的消息。

那client也挂了呢，那这个offset就丢了，必须从过期的offset开始，重新消费一遍。