在公有⼦⽹中，Auto Scaling 组中的允许 SSH 访问的堡垒主机。默认 情况下将 部署⼀台堡垒主机，此数⽬可配置，最多启动 4 台。通过堡垒主 机访问私有⼦⽹ 中的 RocketMQ 相关节点。 • AMAZON Identity and Access Management (IAM) 实例⻆⾊，具有细 化控制的权限， ⽤于访问部署过程所需的 AMAZON WEB SERVICES 2 选择部署 Apache RocketMQ Nameserver 节点的数量。 16 Number of Apache RocketMQ Broker Cluster Node BrokerClusterCount 3 选择部署 Apache RocketMQ Broker 节点的数量。 Page 11 of 21 17 IOPS NameServerInstanceTy pe m5.large Nameserver 节点的 EC2 实例 类型 20 Broker Node Instance Type BrokerNodeInstanceTy pe m5.xlarge Broker 节点 EC2 实例类型 21 Apache RocketMQ flush Disk Type

在公有⼦网中，Auto Scaling 组中的允许 SSH 访问的堡垒主机。默认情况 下将 部署一台堡垒主机，此数目可配置，最多启动 4 台。通过堡垒主机访 问私有⼦网 中的 RocketMQ 相关节点。 • AMAZON Identity and Access Management (IAM) 实例⻆⾊，具有细化控制的 权限， 用于访问部署过程所需的 AMAZON WEB SERVICES 2 选择部署 Apache RocketMQ Nameserver 节点的数量。 16 Number of Apache RocketMQ Broker Cluster Node BrokerClusterCount 3 选择部署 Apache RocketMQ Broker 节点的数量。 17 IOPS Iops 100 如果您选择的是 type NameServerInstanceType m5.large Nameserver 节点的 EC2 实例类 型 20 Broker Node Instance Type BrokerNodeInstanceType m5.xlarge Broker 节点 EC2 实例类型 21 Apache RocketMQ flush Disk Type

1. Nameserver Nameserver 集群，topic 的路由注册中心，为客户端根据 Topic 提供路由服务，从 而引导客户端向 Broker 发送消息。Nameserver 之间的节点不通信。路由信息在 Nameserver 集群中数据一致性采取的最终一致性。 2. Broker 消息存储服务器，分为两种角色：Master 与 Slave，上图中呈现的就是 2 主 2 从的部 opics.json。 在 RocketMQ4.5.0 版本后引入了多副本机制，即一个复制组（m-s）可以演变为基 于 raft 协议的复制组，复制组内部使用 raft 协议保证 broker 节点数据的强一致性，该部署 架构在金融行业用的比较多。 二、消息订阅模型 在 RocketMQ 的消息消费模式采用的是发布与订阅模式。 topic：一类消息的集合，消息发送者将一类消息发送到一个主题中，例如订单模块将 的路由信息只包含在其中一台 Broker 服务器上，这是为什么呢？ 期望值：为了消息发送的高可用，希望新创建的 Topic 在集群中的每台 Broker 上创 建对应的队列，避免 Broker 的单节点故障。 现象截图如下： Broker 集群信息 自动创建的 topicTest5 的路由信息： topicTest5 只在 broker-a 服务器上创建了队列，并没有在 broker-b 服务器创建队

文件保留时间，默认48小时 fileReservedTime=48 # Broker的角色，AYNSC_MASTER=异步复制master，SYNC_MASTER=同步双写master，SLAVE= lave节点 brokerRole=ASYNC_MASTER # 刷盘方式，ASYNC_FLUSH=异步刷盘，SYNC_FLUSH=同步刷盘 flushDiskType=ASYNC_FLUSH # broker对外服务的监听端口 mapedFileSizeCommitLog=1073741824 # ConsumeQueue每个文件默认存30w条，根据业务情况调整 mapedFileSizeConsumeQueue=300000 2、配置slave节点 conf/2m-2s-async/broker-b-s.properties # 集群名称 brokerClusterName=mq-broker-cluster # broker名字，不同的配置文件填写的不一样 文件保留时间，默认48小时 fileReservedTime=48 # Broker的角色，AYNSC_MASTER=异步复制master，SYNC_MASTER=同步双写master，SLAVE= lave节点 brokerRole=SLAVE # 刷盘方式，ASYNC_FLUSH=异步刷盘，SYNC_FLUSH=同步刷盘 flushDiskType=ASYNC_FLUSH # broker对外服务的监听端口

专有云 混合云 EC S 容器 K8S 物理机 经典网络/VPC 网络 Overlay/Underlay NVMe 普通云盘 ESSD 云盘 SA TA 独占/混部/独立交付…… • 集群节点异常成为常态 • 依赖服务随时可能在进行迁移或重启 • 对弹性的要求开始从物理资源变为逻辑资源 • IaaS 的多样性对应用交付部署提出了更高要求 • 可运维性、可观测性带来了更大挑战 • 秒级故障转移，多场景容灾支持 • 无外部依赖，节点间松散耦合 • 自建及云上异构 IaaS 基础设施支持，降低成本 轻量级SDK： • 全面支持云原生通信标准 gRPC 协议 • 无状态 Pop 消费模式，多语言友好，易集成 从业务走向数据： • 事件流场景支撑 • 面向 SQL 的轻量级实时计算引擎 可分可合的存储计算分离： • Broker 升级为真正的无状态服务节点，无 binding • Broker和Store节点分离部署、独立扩缩 • 可分可合，适应多种业务场景，降低运维负担 云原生基础设施： • 可观测性能力云原生化，OpenTelemetry 标准化 • Kubernetes 一键式部署扩容交付 W r i t e h e r e S o m e t h i n g Ab o u t 全新 POP 消费模型 服务端负载均衡  消除 Consumer 与

Slave2 Producer集群 Consumer集群 图表 5-2RocketMQ 网络部署图 RocketMQ 网络部署特点  Name Server 是一个几乎无状态节点，可集群部署，节点乀间无任何信息同步。  Broker 部署相对复杂，Broker 分为 Master 不 Slave，一个 Master 可以对应多个 Slave，但是一个 Slave 只能 对应一个 Producer 不 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 叏 Topic 路 由信息，幵吐提供 Topic 服务的 Master 建立长连接，丏定时吐 Master 収送心跳。Producer 完全无状态，可 集群部署。  Consumer 不 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 下达一个重定吐挃 令，令 Consumer 从 Slave 拉叏数据，返样正常的収消息不正常消费的 Consumer 都丌会因为消息堆积叐影响，因为 系统将堆积场景不非堆积场景分割在了两个丌同的节点处理。返里会产生另一个问题，Slave 会丌会写性能下降， 答案是否定的。因为 Slave 的消息写入只追求吞吏量，丌追求实时性，只要整体的吞吏量高就可以，而 Slave 每次 都是从 Master