集群架构_09RocketMQ集群架构原理

1. 集群部署简化版

场景&＃xff1a;假设有大量的系统要往RocketMQ里高并发的写入消息&＃xff0c;可能达到每秒三十万请求。

集群方案&＃xff1a;对RockeMQ进行集群化部署&＃xff0c;可以发布数在多态机器上&＃xff1b;

当前场景每台机器都能抗10万并发&＃xff0c;部署3台机器&＃xff0c;三十万请求分散到3台机器上&＃xff0c;平均每台机承受的QPS不超过十万。

2.数据分发场景

RocketMQ对接收到的消息是先把消息落盘&＃xff0c;然后再等待消费者获取消息去处理的。

假设&＃xff0c;当前的场景有3000条数据要&＃xff0c;分散发送给3台机器&＃xff0c;那么每台机器就接收到1000条消息&＃xff0c;然后进行落盘。

3.集群存储海量消息场景

场景&＃xff1a;如果一台Broker突然宕机了怎么办&＃xff1f;会不会导致RocketMQ里一部分的消息就没了吗&＃xff1f;

解决思路&＃xff1a;采用Broker主从架构以及多副本策略。

流程&＃xff1a;Master Broker 收到消息之后会同步给Slave Broker&＃xff0c;这样Slave Broker上就能有一模一样的一份副本数据。这样在RocketMQ集群中就有两份副本数据了。

高可用实现&＃xff1a;如果任何一个Master Broker出现故障&＃xff0c;还有一个Slave Broker上有一个数据副本&＃xff0c;可以保证数据不丢失&＃xff0c;还能继续对外提供服务&＃xff0c;保证了MQ的可靠性和高可用性。

4.NameServer —— Broker注册

NameServer概念&＃xff1a;RocketMQ中有NameServer这个概念。它也是独立部署在几台机器上的&＃xff0c;然后所有的Broker都会把自己注册到NameServer上。

应用&＃xff1a;如果系统要从Broker获取信息&＃xff0c;就会从NameServer获取路由信息&＃xff0c;从而找到对应的Broker获取信息。

5.完整架构图