基于电商场景的高并发RocketMQ实战-读写分离主从漂移设计、Broker基于raft协议的主从架构设计

🌈🌈🌈🌈🌈🌈🌈🌈
【11来了】文章导读地址：点击查看文章导读！
🍁🍁🍁🍁🍁🍁🍁🍁

RocketMQ 读写分离主从漂移设计

默认情况下，RocketMQ 是不倾向于主动进行读写分离的，在默认情况下，读和写操作都是在 主节点 上进行的，从节点主要是用于进行复制和同步操作，实现热备份

如果主节点过于繁忙呢？

主节点过于繁忙时，返回给消费者一个从节点的 brokerId ，之后在从节点中拉取数据，当从节点拉取消息过程非常顺利的时候，此时又会返回给消费者一个 brokerId，让消费者去主节点进行消费，再漂移回主节点

那么这种方式就是 主从漂移模式，即主从集群对外提供服务，用户在访问时，有时候访问主，有时候访问从，主从之间来回漂移

即 RocketMQ 一开始不进行读写分离，当主节点压力过大，积压消息达到了自己物理内存的 40% 之后，才进行读写分离，将消费者消费的请求 漂移到从节点去 ，分散主节点的压力

如果主节点崩溃了，也会将消费者请求 漂移到从节点中

当漂移到从节点之后，消息积压数量很快就得到了环节，即消息积压降低到了从节点物理内存的 30% 以内，说明此时消费的情况比较良好，又会将消费的请求 漂移回主节点中

那么为什么要设计为惰性的主从分离机制呢？

在消费的过程中，对于每个 queue 都需要记录这个队列消费的进度 offset，那么如果消费者每次随机挑选一台机器进行消费，那么就会导致每台机器上维护的这个消费进度 offset 混乱

因此默认情况下，都会优先去主节点进行消费，当漂移到从节点之后，每隔 10s 时间，主从节点之间还会进行消费的一些元数据的同步（偏移量等等），这样再漂移回主节点后还可以接着进行消费

Broker 基于 raft 协议的主从架构设计

在 RocketMQ 4.5.0 之前，Broker 主节点崩溃了之后，是没有高可用主从切换机制的，主从仅仅是用于进行 热备份 的，此时从节点是不可以进行写入数据的

在 4.5.0 之后，做出了架构改造，添加了 高可用机制 ：主从复制 + 主从切换

那么启动 Broker 之后，Broker 之间会通过 Raft 协议选举出来主节点，之后生产者会向主节点中不停地写入消息，主节点将消息再同步给从节点，只要超过集群中一般节点写入成功（包括主节点，也就是主节点+从节点超过一半节点都写入消息成功），Broker 就返回给生产者写入消息成功

如果主节点挂了之后，会通过 Raft 协议重新选举主节点，进行消息写入