RocketMQ系列(七)：主从同步

RocketMQ.png

先引几个问题

• 主从同步的过程
• 只从的作用是什么，读写分离还是HA
• 什么样的请求打到主，什么样的请求打到从
• 主挂了的后续动作

主从同步过程

主从同步过程.png

1. 首先启动Master并在指定接口监听
2. Slave启动，主动连接Master，简历TCP连接
3. Slave以5秒的时间间隔向Mater拉取消息，如果是第一次拉取的话，先获取本地commitLog文件中的最大偏移量，以该offset向master拉取
4. master收到请求，并返回请求offset的数据给slave
5. slave收到一批消息后，将消息写入到本地commitLog文件中，然后向master汇报拉取进度，并更新下一次待拉取偏移量
6. 重复执行3-5

主从的作用是什么

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

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

什么样的请求打到主，什么样的请求打到从

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

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

来，看源码

long diff = maxOffsetPy - maxPhyOffsetPulling;  // 1
long memory = (long) (StoreUtil.TOTAL_PHYSICAL_MEMORY_SIZE * (this.messageStoreConfig.getAccessMessageInMemoryMaxRatio() / 100.0));  // 2
getResult.setSuggestPullingFromSlave(diff > memory);   // 3

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

• StoreUtil.TOTAL_PHYSICAL_MEMORY_SIZE 当前系统的总物理内存
• getAccessMessageInMemoryMaxRatio()。默认为40

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

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

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

主挂了的后续动作

• master挂了，slave接管消息消费后，消息消费进度存在哪呢？？？
• master恢复后，消息从master拉，还是slave拉
• 从master拉，master怎么知道最新的offset呢

master挂了，slave接管消息消费后，消息消费进度存在哪呢？？？

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

offset存在slave的

{ROCKETMQ_HOME}/store/config/consumerOffset.json中

中

master恢复后，消息从master拉，还是slave拉

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

从master拉，master怎么知道最新的offset呢

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开始，重新消费一遍。