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 为拓扑结构。

原文地址:https://www.cnblogs.com/zuoyang/p/14436419.html