本文深入探讨RocketMQ的部署，包括NameServer、Broker集群的搭建，阐述了Broker与NameServer间的TCP长连接通信机制。同时介绍了生产者如何通过负载均衡算法选择Broker发送消息，消费者如何消费消息，以及RocketMQ的整体高可用架构。此外，还提及了Kafka的相关知识点。
NameServer的部署
关于NameServer，我们之前的文章已经详细讲解过了集群化的内容，这里直接把它部署到三台机器上，作为一个高可用集群
Broker的部署
Broker的部署我们之前也有讲到过，主要使用的是4.5版本后的Dledger自动化切换主从的集群
Broker与NameServer之间的通信协议是什么呢？http、rpc还是tcp呢？
其实它们之间采用的是TCP长连接通信，也就是说Broker会跟每个NameServer建立TCP长连接，然后定时通过TCP长连接发送心跳请求过去。
访问MQ的系统（生产者和消费者）的部署
一定会有大量的系统访问RocketMQ，因为RocketMQ就是为此而生的，有些系统自己本身既是生产者又是消费者，所以这些系统的部署也要考虑进去。
对这些系统部署的考虑，其实不应该是搞MQ的部门来考虑的，如果系统本身是自己公司的，可以提出一些建议，让生产者和消费者都集群化部署，保证高可用。但如果是第三方系统，那就无法插手了，我们能做到的只有考虑第三方系统崩溃，无法与MQ正常通信的情况下，如何让MQ正常运转。
Topic是什么
Topic是mq的核心数据模型，如果直接翻译是主题的意思，但是听到主题的解释，是不是一脸懵逼，是不是瞬间想到的是手机主题，电脑主题。
所以它不能直译，它表达的就是一个数据集合
最低0.47元/天 解锁文章
1178
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
