RocketMQ(4.8.0)——RocketMQ部署拓扑和部署实践

RocketMQ部署拓扑和部署实践

一、常用的拓扑图

常用的 RocketMQ 的部署拓扑方式有 5 种，不同的部署方式可靠性不同。

　　一个基本的部署拓扑至少包含 Console 管理平台、Namesrv 和 Broker：

• Namesrv 部署：推荐一个集群并部署 2~3 个Namesrv 节点。
• Broker 部署：Broker部署方式有5种，下个章节细说。

第一种：单 Master。"集群"中只有一个节点，宕机后不可用。通常用于个人入门学习，比如测试发送消息代码、测试消费消息代码等，建议在生产环境中不要使用这种部署方式。

第二种：单 Master，单 Slave。单主从模式，Master 宕机后集群不可写入消息，但可以读取消息。通常用于个人深入学习，比如研究源码、设计原理等，建议在生产环境中不要使用这种部署方式。

第三种：多 Master，无 Slave。这种部署方式性能最好，并且当单个 Master 节点宕机时，不影响正常使用。

第四种：多 Master、多 Salve，异步复制。在第三种方式上增加了 Slave，当一个 Master 节点宕机时，该 Master 不能写入消息，消费可以在其对应的 Slave 上进行。新消息的生产、消费不受影响。添加 Slave 后，消费者可以从对应的 Slave 中读取已发送到宕机 Master 中的消息。生产环境可以使用这种部署方式。

第五种：多 Master，多 Slave，同步复制。这种部署方式完全解决了第四种部署方式的弊端，虽然由于 Master-Slave 同步复制导致发送消息耗时增加，集群性能大大下降，但是这仍然是最可靠的部署方式。生产环境中可以使用这种部署方式。

二、同步复制、异步复制和同步刷盘、异步刷盘

　　复制是指 Broker 与 Broker 之间的数据同步方式。分为同步和异步两种，同步复制时，生产者会等待同步复制成功后，才返回生产者消息发送成功；异步复制时，消息写入 Master Broker 后即为写入成功，此时系统有较低的写入延迟和较大的系统吞吐量。 

 

　　刷盘是指数据发送到 Broker 的内存（通常指 PageCache）后，以何种方式持久化到磁盘。同步刷盘时，生产者会等待数据持久化到磁盘后，才返回生产者消息发送成功，可靠性极强；异步刷盘时，消息写入 PageCache 即为写入成功，达到一定量时自动触发刷盘。此时系统有非常低的写入延迟和非常大的系统吞吐量。

　　结合业务自身的属性合理配置主从同步方式和刷盘方式，大部分场景下使用异步复制、异步刷盘即可满足。

三、部署实践

　　本次实践以 2Namesrv + 2Master + 2Slave + 1Console 为拓扑结构。