先引几个问题
- 主从同步的过程
- 只从的作用是什么，读写分离还是HA
- 什么样的请求打到主，什么样的请求打到从
- 主挂了的后续动作
主从同步过程
- 首先启动Master并在指定接口监听
- Slave启动，主动连接Master，简历TCP连接
- Slave以5秒的时间间隔向Mater拉取消息，如果是第一次拉取的话，先获取本地commitLog文件中的最大偏移量，以该offset向master拉取
- master收到请求，并返回请求offset的数据给slave
- slave收到一批消息后，将消息写入到本地commitLog文件中，然后向master汇报拉取进度，并更新下一次待拉取偏移量
- 重复执行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开始，重新消费一遍。
