网站服务器租用和托管,陵水网站建设价格,上海专业网站建设机构,小程序localstorage本文尝试从Apache RocketMQ的简介、主要组件及其作用、3种部署模式、Controller集群模式工作流程、最佳实践等方面对其进行详细分析。希望对您有所帮助#xff01;
一、Apache RocketMQ 简介
Apache RocketMQ 是一个开源的分布式消息中间件#xff0c;由阿里巴巴集团开发并…本文尝试从Apache RocketMQ的简介、主要组件及其作用、3种部署模式、Controller集群模式工作流程、最佳实践等方面对其进行详细分析。希望对您有所帮助
一、Apache RocketMQ 简介
Apache RocketMQ 是一个开源的分布式消息中间件由阿里巴巴集团开发并贡献给 Apache 软件基金会。它旨在提供高吞吐量、低延迟和高可靠性的消息传递和流处理服务。广泛应用于金融、互联网、物联网等领域支持多种应用场景。
核心特性
1. 高性能
高吞吐量支持每秒处理数百万条消息适用于高并发的业务场景。低延迟具备低于毫秒级的延迟确保消息能够快速传递。
2. 高可靠性
数据一致性通过消息确认和重新传递机制确保消息的可靠传递。消息持久化支持消息持久化保证在系统故障时消息不丢失。
3. 可扩展性
水平扩展支持通过增加节点的方式水平扩展满足业务增长需求。弹性伸缩根据业务负载动态调整资源提升资源利用效率。
4. 灵活性
多种消息模型支持点对点、发布/订阅、流处理等多种消息传递模型满足不同应用需求。丰富的接口提供Java、C、Python等多种语言的客户端接口便于集成和使用。
关键功能和支持特性
Producer生产者负责发送消息到 RocketMQ 集群。生产者可以指定消息的主题Topic和标签Tag便于消息分类和筛选。Consumer消费者负责从 RocketMQ 集群接收和处理消息。消费者分为集群消费和广播消费两种模式。NameServer命名服务器提供轻量级的路由服务存储生产者和消费者与 Broker 之间的路由信息。支持动态扩展确保系统的高可用性。Broker代理服务器负责存储和转发消息。Broker 将消息存储在磁盘上并根据需要将消息传递给消费者。支持主从架构提升系统的容错能力和数据可靠性。事务消息支持分布式事务消息确保在分布式系统中实现最终一致性。事务消息可以确保消息在事务成功时被发送事务失败时被回滚。顺序消息支持顺序消息传递确保消息按照发送顺序被消费。定时消息和延时消息支持消息定时发送和延时发送满足特定的业务需求。批量消息支持批量消息发送提高消息传递效率。消息过滤支持基于标签的消息过滤消费者可以根据标签选择性地接收消息。消息重试支持消息重试机制确保消息在消费失败时可以重新消费。死信队列DLQ支持死信队列确保处理失败的消息不会丢失。流量控制支持流量控制防止系统过载。分布式架构支持多数据中心部署和跨地域部署提升系统的高可用性和容灾能力。监控和管理提供完善的监控和管理工具支持消息统计、系统监控和运维管理。安全性支持基于权限的访问控制确保消息传递的安全性。
使用场景
异步通信在分布式系统中实现异步消息传递解耦系统组件提升系统的响应速度和可靠性。事件驱动架构构建基于事件的系统通过消息队列实现事件驱动的业务逻辑提升系统的灵活性和可维护性。日志收集集中收集和处理分布式系统中的日志信息实现统一的日志管理和分析。流处理实时处理和分析数据流支持大数据分析、实时监控等应用场景。
优势
高性能、高吞吐量适用于大规模、高并发的业务场景。强一致性通过严格的消息确认机制确保数据一致性。灵活的扩展性支持弹性伸缩能够适应业务的快速变化。多语言支持提供多种语言的客户端接口便于开发和集成。
Apache RocketMQ 以其高性能、高可靠性和灵活性成为众多企业实现分布式消息传递和流处理的首选解决方案。
二、RocketMQ 主要组件及其作用
Apache RocketMQ 主要组件及其作用如下
1. NameServer命名服务器
作用提供轻量级的路由服务存储生产者和消费者与 Broker 之间的路由信息。
路由管理维护 Broker 的地址列表和路由信息供生产者和消费者查询。动态注册Broker 启动时向 NameServer 注册定期发送心跳以保持连接。高可用性可以部署多个 NameServer实现高可用。
2. Broker代理服务器
作用负责存储和转发消息是 RocketMQ 的核心组件。
消息存储持久化存储消息确保数据的可靠性和持久性。消息转发将消息从生产者传递到消费者。主从架构支持主从模式主 Broker 负责消息处理从 Broker 备份数据提供容错能力。消息索引通过建立消息索引提高消息检索效率。
3. Producer生产者
作用负责发送消息到 RocketMQ 集群。
消息生成创建并发送消息到指定的主题Topic。异步发送支持异步消息发送提高发送性能。路由获取通过 NameServer 获取 Broker 路由信息将消息发送到合适的 Broker。
4. Consumer消费者
作用负责从 RocketMQ 集群接收和处理消息。
消息消费从指定的主题Topic接收并处理消息。消费模式支持集群消费和广播消费两种模式。 集群消费同一消费组内的多个消费者负载均衡地处理消息每条消息只会被一个消费者处理一次。广播消费每个消费者都会处理所有的消息每条消息会被所有消费者处理一次。 消息过滤可以根据标签Tag进行消息过滤选择性接收和处理消息。
5. Controller控制器
作用管理主从 Broker 的自动故障转移和高可用性。
事务管理负责分布式事务的管理确保消息在事务成功时被发送事务失败时被回滚。状态监控监控 Broker 的状态在主 Broker 发生故障时自动将从 Broker 提升为新的主 Broker。协调主从在 Broker 间协调主从关系确保系统的高可用性和数据一致性。
6. RocketMQ Console管理控制台
作用提供可视化的运维管理工具。
集群监控实时监控 RocketMQ 集群的运行状态包括 Broker、Topic、Consumer 等信息。消息查询支持消息的精确查询和模糊查询方便运维人员排查问题。配置管理提供 Topic、Consumer Group、Broker 配置的管理功能。
7. Store消息存储
作用实现消息的持久化存储。
CommitLog存储所有消息的物理文件按顺序写入支持快速写入操作。ConsumeQueue消息的逻辑队列记录消息在 CommitLog 中的位置便于消费者快速检索。IndexFile消息索引文件通过消息的属性如消息键建立索引支持快速查询。
8. Client客户端
作用包含 Producer 和 Consumer 的客户端 SDK。
API 提供提供 Java、C、Python 等多种语言的客户端接口便于集成和使用。消息操作支持消息的发送、接收、过滤、批处理等操作。
总结
最新版本的 Apache RocketMQ 通过这些组件的协同工作提供了高性能、高可靠性和高可扩展性的分布式消息传递和流处理服务。各个组件分工明确确保系统能够高效、稳定地运行并满足各种复杂业务场景的需求。
三、RocketMQ 部署方式介绍
Apache RocketMQ 5.0 版本完成基本消息收发包括 NameServer、Broker、Proxy 组件。 在 5.0 版本中 Proxy 和 Broker 根据实际诉求可以分为 Local 模式和 Cluster 模式一般情况下如果没有特殊需求或者遵循从早期版本平滑升级的思路可以选用Local模式。
Local 模式
在 Local 模式下Broker 和 Proxy 是同进程部署只是在原有 Broker 的配置基础上新增 Proxy 的简易配置就可以运行。
Cluster 模式
在 Cluster 模式下Broker 和 Proxy 分别部署即在原有的集群基础上额外再部署 Proxy 即可。
主备自动切换模式
主备自动切换模式部署方式下主要增加支持自动主从切换的 Controller 组件它可以独立部署也可以内嵌在 NameServer 中。
下文分别介绍三种部署方式
四、Local模式部署
由于 Local 模式下 Proxy 和 Broker 是同进程部署Proxy本身无状态因此主要的集群配置仍然以 Broker 为基础进行即可。
启动 NameServer
NameServer需要先于Broker启动且如果在生产环境使用为了保证高可用建议一般规模的集群启动3个NameServer各节点的启动命令相同如下
### 首先启动Name Server
$ nohup sh mqnamesrv ### 验证Name Server 是否启动成功
$ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...启动BrokerProxy
单组节点单副本模式
警告
这种方式风险较大因为 Broker 只有一个节点一旦Broker重启或者宕机时会导致整个服务不可用。不建议线上环境使用, 可以用于本地测试。
启动 BrokerProxy
$ nohup sh bin/mqbroker -n localhost:9876 --enable-proxy ### 验证Broker 是否启动成功例如Broker的IP为192.168.1.2且名称为broker-a
$ tail -f ~/logs/rocketmqlogs/broker_default.log
The broker[xxx, 192.169.1.2:10911] boot success...多组节点集群单副本模式
一个集群内全部部署 Master 角色不部署Slave 副本例如2个Master或者3个Master这种模式的优缺点如下 优点配置简单单个Master宕机或重启维护对应用无影响在磁盘配置为RAID10时即使机器宕机不可恢复情况下由于RAID10磁盘非常可靠消息也不会丢异步刷盘丢失少量消息同步刷盘一条不丢性能最高 缺点单台机器宕机期间这台机器上未被消费的消息在机器恢复之前不可订阅消息实时性会受到影响。
启动BrokerProxy集群
### 在机器A启动第一个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties --enable-proxy ### 在机器B启动第二个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties --enable-proxy ...备注
如上启动命令是在单个NameServer情况下使用的。对于多个NameServer的集群Broker启动命令中-n后面的地址列表用分号隔开即可例如 192.168.1.1:9876;192.161.2:9876。
多节点集群多副本模式-异步复制
每个Master配置一个Slave有多组 Master-SlaveHA采用异步复制方式主备有短暂消息延迟毫秒级这种模式的优缺点如下 优点即使磁盘损坏消息丢失的非常少且消息实时性不会受影响同时Master宕机后消费者仍然可以从Slave消费而且此过程对应用透明不需要人工干预性能同多Master模式几乎一样 缺点Master宕机磁盘损坏情况下会丢失少量消息。
启动BrokerProxy集群
### 在机器A启动第一个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a.properties --enable-proxy ### 在机器B启动第二个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties --enable-proxy ### 在机器C启动第一个Slave例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties --enable-proxy ### 在机器D启动第二个Slave例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties --enable-proxy 多节点集群多副本模式-同步双写
每个Master配置一个Slave有多对 Master-SlaveHA采用同步双写方式即只有主备都写成功才向应用返回成功这种模式的优缺点如下 优点数据与服务都无单点故障Master宕机情况下消息无延迟服务可用性与数据可用性都非常高 缺点性能比异步复制模式略低大约低10%左右发送单个消息的RT会略高且目前版本在主节点宕机后备机不能自动切换为主机。
启动 BrokerProxy 集群
### 在机器A启动第一个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a.properties --enable-proxy ### 在机器B启动第二个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties --enable-proxy ### 在机器C启动第一个Slave例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties --enable-proxy ### 在机器D启动第二个Slave例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties --enable-proxy 提示
以上 Broker 与 Slave 配对是通过指定相同的 BrokerName 参数来配对Master 的 BrokerId 必须是 0Slave 的 BrokerId 必须是大于 0 的数。另外一个 Master 下面可以挂载多个 Slave同一 Master 下的多个 Slave 通过指定不同的 BrokerId 来区分。$ROCKETMQ_HOME指的RocketMQ安装目录需要用户自己设置此环境变量。
5.0 HA新模式
提供更具灵活性的HA机制让用户更好的平衡成本、服务可用性、数据可靠性同时支持业务消息和流存储的场景。详见
五、Cluster模式部署
在 Cluster 模式下Broker 与 Proxy分别部署我可以在 NameServer和 Broker都启动完成之后再部署 Proxy。
在 Cluster模式下一个 Proxy集群和 Broker集群为一一对应的关系可以在 Proxy的配置文件 rmq-proxy.json 中使用 rocketMQClusterName 进行配置
启动 NameServer
### 首先启动Name Server
$ nohup sh mqnamesrv ### 验证Name Server 是否启动成功
$ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...单组节点单副本模式
警告
这种方式风险较大因为 Broker 只有一个节点一旦Broker重启或者宕机时会导致整个服务不可用。不建议线上环境使用, 可以用于本地测试。
### 在机器A启动第一个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 多组节点集群单副本模式
一个集群内全部部署 Master 角色不部署Slave 副本例如2个Master或者3个Master这种模式的优缺点如下 优点配置简单单个Master宕机或重启维护对应用无影响在磁盘配置为RAID10时即使机器宕机不可恢复情况下由于RAID10磁盘非常可靠消息也不会丢异步刷盘丢失少量消息同步刷盘一条不丢性能最高 缺点单台机器宕机期间这台机器上未被消费的消息在机器恢复之前不可订阅消息实时性会受到影响。
### 在机器A启动第一个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties ### 在机器B启动第二个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties ...如上启动命令是在单个NameServer情况下使用的。对于多个NameServer的集群Broker启动命令中-n后面的地址列表用分号隔开即可例如 192.168.1.1:9876;192.161.2:9876。
多节点集群多副本模式-异步复制
每个Master配置一个Slave有多组 Master-SlaveHA采用异步复制方式主备有短暂消息延迟毫秒级这种模式的优缺点如下 优点即使磁盘损坏消息丢失的非常少且消息实时性不会受影响同时Master宕机后消费者仍然可以从Slave消费而且此过程对应用透明不需要人工干预性能同多Master模式几乎一样 缺点Master宕机磁盘损坏情况下会丢失少量消息。
### 在机器A启动第一个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a.properties ### 在机器B启动第二个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties ### 在机器C启动第一个Slave例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties ### 在机器D启动第二个Slave例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties 多节点集群多副本模式-同步双写
每个Master配置一个Slave有多对 Master-SlaveHA采用同步双写方式即只有主备都写成功才向应用返回成功这种模式的优缺点如下 优点数据与服务都无单点故障Master宕机情况下消息无延迟服务可用性与数据可用性都非常高 缺点性能比异步复制模式略低大约低10%左右发送单个消息的RT会略高且目前版本在主节点宕机后备机不能自动切换为主机。
### 在机器A启动第一个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a.properties ### 在机器B启动第二个Master例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties ### 在机器C启动第一个Slave例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties ### 在机器D启动第二个Slave例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties 提示
以上 Broker 与 Slave 配对是通过指定相同的 BrokerName 参数来配对Master 的 BrokerId 必须是 0Slave 的 BrokerId 必须是大于 0 的数。另外一个 Master 下面可以挂载多个 Slave同一 Master 下的多个 Slave 通过指定不同的 BrokerId 来区分。$ROCKETMQ_HOME指的RocketMQ安装目录需要用户自己设置此环境变量。
5.0 HA新模式
提供更具灵活性的HA机制让用户更好的平衡成本、服务可用性、数据可靠性同时支持业务消息和流存储的场景。详见
启动 Proxy
可以在多台机器启动多个Proxy
### 在机器A启动第一个Proxy例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqproxy -n 192.168.1.1:9876 ### 在机器B启动第二个Proxy例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqproxy -n 192.168.1.1:9876 ### 在机器C启动第三个Proxy例如NameServer的IP为192.168.1.1
$ nohup sh bin/mqproxy -n 192.168.1.1:9876 若需要指定配置文件可以使用 -pc或者 --proxyConfigPath 进行指定
### 自定义配置文件
$ nohup sh bin/mqproxy -n 192.168.1.1:9876 -pc /path/to/proxyConfig.json 六、主备自动切换模式部署 如何部署支持自动主从切换的 RocketMQ 集群 其架构如上图所示主要增加支持自动主从切换的 Controller 组件其可以独立部署也可以内嵌在 NameServer 中。
Controller 部署
Controller 组件提供选主能力若需要保证 Controller 具备容错能力Controller 部署需要三副本及以上遵循 Raft 的多数派协议。
注意
Controller 若只部署单副本也能完成 Broker Failover但若该单点 Controller 故障会影响切换能力但不会影响存量集群的正常收发。
Controller 部署有两种方式。一种是嵌入于 NameServer 进行部署可以通过配置 enableControllerInNamesrv 打开可以选择性打开并不强制要求每一台 NameServer 都打开在该模式下NameServer 本身能力仍然是无状态的也就是内嵌模式下若 NameServer 挂掉多数派只影响切换能力不影响原来路由获取等功能。另一种是独立部署需要单独部署 Controller 组件。
Controller 嵌入 NameServer 部署 嵌入 NameServer 部署时只需要在 NameServer 的配置文件中设置 enableControllerInNamesrvtrue并填上 Controller 的配置即可。
enableControllerInNamesrv true
controllerDLegerGroup group1
controllerDLegerPeers n0-127.0.0.1:9877;n1-127.0.0.1:9878;n2-127.0.0.1:9879
controllerDLegerSelfId n0
controllerStorePath /home/admin/DledgerController
enableElectUncleanMaster false
notifyBrokerRoleChanged true参数解释
enableControllerInNamesrvNameserver 中是否开启 controller默认 false。controllerDLegerGroupDLedger Raft Group 的名字同一个 DLedger Raft Group 保持一致即可。controllerDLegerPeersDLedger Group 内各节点的端口信息同一个 Group 内的各个节点配置必须要保证一致。controllerDLegerSelfId节点 id必须属于 controllerDLegerPeers 中的一个同 Group 内各个节点要唯一。controllerStorePathcontroller 日志存储位置。controller 是有状态的controller 重启或宕机需要依靠日志来恢复数据该目录非常重要不可以轻易删除。enableElectUncleanMaster是否可以从 SyncStateSet 以外选举 Master若为 true可能会选取数据落后的副本作为 Master 而丢失消息默认为 false。notifyBrokerRoleChanged当 Broker 副本组上角色发生变化时是否主动通知默认为 true。
参数设置完成后指定配置文件启动 Nameserver 即可。
$ nohup sh bin/mqnamesrv -c namesrv.conf Controller 独立部署 独立部署执行以下脚本即可
$ nohup sh bin/mqcontroller -c controller.conf mqcontroller 脚本在源码包 distribution/bin/mqcontroller配置参数与内嵌模式相同。
注意
独立部署Controller后仍然需要单独部署NameServer提供路由发现能力
Broker 部署
Broker 启动方法与之前相同增加以下参数
enableControllerModeBroker controller 模式的总开关只有该值为 true自动主从切换模式才会打开。默认为 false。controllerAddrcontroller 的地址多个 controller 中间用分号隔开。例如controllerAddr 127.0.0.1:9877;127.0.0.1:9878;127.0.0.1:9879syncBrokerMetadataPeriod向 controller 同步 Broker 副本信息的时间间隔。默认 50005s。checkSyncStateSetPeriod检查 SyncStateSet 的时间间隔检查 SyncStateSet 可能会 shrink SyncState。默认50005s。syncControllerMetadataPeriod同步 controller 元数据的时间间隔主要是获取 active controller 的地址。默认1000010s。haMaxTimeSlaveNotCatchup表示 Slave 没有跟上 Master 的最大时间间隔若在 SyncStateSet 中的 slave 超过该时间间隔会将其从 SyncStateSet 移除。默认为 1500015s。storePathEpochFile存储 epoch 文件的位置。epoch 文件非常重要不可以随意删除。默认在 store 目录下。allAckInSyncStateSet若该值为 true则一条消息需要复制到 SyncStateSet 中的每一个副本才会向客户端返回成功可以保证消息不丢失。默认为 false。syncFromLastFile若 slave 是空盘启动是否从最后一个文件进行复制。默认为 false。asyncLearner若该值为 true则该副本不会进入 SyncStateSet也就是不会被选举成 Master而是一直作为一个 learner 副本进行异步复制。默认为false。inSyncReplicas需保持同步的副本组数量默认为1allAckInSyncStateSettrue 时该参数无效。minInSyncReplicas最小需保持同步的副本组数量若 SyncStateSet 中副本个数小于 minInSyncReplicas 则 putMessage 直接返回 PutMessageStatus.IN_SYNC_REPLICAS_NOT_ENOUGH默认为1。
在Controller模式下Broker配置必须设置 enableControllerModetrue并填写 controllerAddr并以下面命令启动
$ nohup sh bin/mqbroker -c broker.conf 注意
自动主备切换模式下Broker无需指定brokerId和brokerRole其由Controller组件进行分配
兼容性
该模式未对任何客户端层面 API 进行新增或修改不存在客户端的兼容性问题。
Nameserver 本身能力未做任何修改Nameserver 不存在兼容性问题。如开启 enableControllerInNamesrv 且 controller 参数配置正确则开启 controller 功能。
Broker若设置 enableControllerModefalse则仍然以之前方式运行。若设置 enableControllerModetrue则需要部署 controller 且参数配置正确才能正常运行。
具体行为如下表所示
旧版 Nameserver旧版 Nameserver独立部署 Controller新版 Nameserver 开启 controller功能新版 Nameserver 关闭 controller 功能旧版 Broker正常运行无法切换正常运行无法切换正常运行无法切换正常运行无法切换新版 Broker 开启 Controller 模式无法正常上线正常运行可以切换正常运行可以切换无法正常上线新版 Broker 不开启 Controller 模式正常运行无法切换正常运行无法切换正常运行无法切换正常运行无法切换
升级注意事项
从上述兼容性表述可以看出NameServer 正常升级即可无兼容性问题。在不想升级 Nameserver 情况可以独立部署 Controller 组件来获得切换能力。
针对 Broker 升级分为两种情况
1Master-Slave 部署升级成 Controller 切换架构
可以带数据进行原地升级对于每组 Broker停机主、备 Broker保证主、备的 CommitLog 对齐可以在升级前禁写该组 Broker 一段时间或则通过拷贝方式保证一致升级包后重新启动即可。
注意
若主备 CommitLog 不对齐需要保证主上线以后再上线备否则可能会因为数据截断而丢失消息。
2原 DLedger 模式升级到 Controller 切换架构
由于原 DLedger 模式消息数据格式与 Master-Slave 下数据格式存在区别不提供带数据原地升级的路径。在部署多组 Broker 的情况下可以禁写某一组 Broker 一段时间只要确认存量消息被全部消费即可比如根据消息的保存时间来决定然后清空 store 目录下除 config/topics.json、subscriptionGroup.json 下保留 topic 和订阅关系的元数据的其他文件后进行空盘升级。
七、Rocketmq Controller集群模式的工作流程
在 RocketMQ 的集群模式下Controller 负责管理多个 Broker 的元数据和协调它们的操作。下面是集群模式下的工作流程和 Mermaind 图示例。
工作流程 启动 Controller 启动多个 Controller 节点形成一个高可用的 Controller 集群。Controller 节点通过 Raft 协议选举出一个 Leader其他节点为 Follower。 启动 Broker Broker 启动时会向 Controller 集群注册获取元数据和配置信息。Broker 定期向 Controller 报告其状态和心跳信息。 元数据管理 Controller 负责维护 Broker 的元数据包括 Broker 地址、Topic 分配信息等。Controller 处理 Broker 的注册、注销和状态变更并将这些变更通知给其他 Broker。 协调操作 当有新的 Topic 或者 Queue 需要创建时客户端向 Controller 发送请求。Controller 负责选择合适的 Broker 并执行创建操作。Controller 负责处理 Broker 故障重新分配 Topic 和 Queue。 数据同步 主 Broker 负责处理写请求从 Broker 负责处理读请求。主从 Broker 之间通过同步机制保持数据一致性。
Mermaind 图
以下是表示 RocketMQ 集群模式下 Controller 工作流程的 Mermaind 图示例 #mermaid-svg-6ZiyOaOZMYevYezd {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-6ZiyOaOZMYevYezd .error-icon{fill:#552222;}#mermaid-svg-6ZiyOaOZMYevYezd .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-6ZiyOaOZMYevYezd .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-6ZiyOaOZMYevYezd .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-6ZiyOaOZMYevYezd .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-6ZiyOaOZMYevYezd .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-6ZiyOaOZMYevYezd .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-6ZiyOaOZMYevYezd .marker{fill:#333333;stroke:#333333;}#mermaid-svg-6ZiyOaOZMYevYezd .marker.cross{stroke:#333333;}#mermaid-svg-6ZiyOaOZMYevYezd svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-6ZiyOaOZMYevYezd .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-6ZiyOaOZMYevYezd .cluster-label text{fill:#333;}#mermaid-svg-6ZiyOaOZMYevYezd .cluster-label span{color:#333;}#mermaid-svg-6ZiyOaOZMYevYezd .label text,#mermaid-svg-6ZiyOaOZMYevYezd span{fill:#333;color:#333;}#mermaid-svg-6ZiyOaOZMYevYezd .node rect,#mermaid-svg-6ZiyOaOZMYevYezd .node circle,#mermaid-svg-6ZiyOaOZMYevYezd .node ellipse,#mermaid-svg-6ZiyOaOZMYevYezd .node polygon,#mermaid-svg-6ZiyOaOZMYevYezd .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-6ZiyOaOZMYevYezd .node .label{text-align:center;}#mermaid-svg-6ZiyOaOZMYevYezd .node.clickable{cursor:pointer;}#mermaid-svg-6ZiyOaOZMYevYezd .arrowheadPath{fill:#333333;}#mermaid-svg-6ZiyOaOZMYevYezd .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-6ZiyOaOZMYevYezd .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-6ZiyOaOZMYevYezd .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-6ZiyOaOZMYevYezd .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-6ZiyOaOZMYevYezd .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-6ZiyOaOZMYevYezd .cluster text{fill:#333;}#mermaid-svg-6ZiyOaOZMYevYezd .cluster span{color:#333;}#mermaid-svg-6ZiyOaOZMYevYezd div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-6ZiyOaOZMYevYezd :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} Broker Cluster Controller Cluster Create Topic Select Broker Select Broker Create Topic Create Topic Report Status Report Status Report Status Notify Brokers Notify Brokers Notify Brokers Handle Write Requests Handle Read Requests Broker Node 1 Broker Node 2 Broker Node 3 Controller Node 1 Controller Node 2 Controller Node 3 Client 这张图展示了 Controller 和 Broker 之间的交互流程Controller 负责管理元数据、协调 Broker 操作并在 Broker 之间分配任务和同步数据。
八、RocketMQ最佳实践
1. 集群部署
主备部署
多主多备在生产环境中推荐使用多主多备的部署方式。多个主节点Master和备份节点Slave可以确保在主节点发生故障时备份节点能够快速接管保证系统的高可用性。跨机房部署将 Broker 分布在不同的机房以防止单个机房故障导致服务不可用。
NameServer 高可用
多 NameServer 部署至少部署三个 NameServer 节点以确保高可用性。NameServer 是无状态的客户端可以随机选择一个 NameServer 进行连接。定期检查定期检查 NameServer 的状态确保其处于正常工作状态。
Broker 分片
分片部署将 Broker 分成多个分片分布在不同的物理服务器上。这样即使某个 Broker 出现故障也不会影响到整个系统的运行。合理分配 Topic将 Topic 分配到不同的分片中避免单个分片承载过多的消息流量。
2. 消息存储
消息持久化
开启持久化确保消息的持久化功能开启防止因 Broker 异常重启导致的消息丢失。可以在 Broker 配置文件中设置 flushDiskTypeSYNC_FLUSH 来开启同步刷盘。
存储路径
选择高性能磁盘将消息存储路径设置在性能较好的 SSD 磁盘上提升存储和读取效率。分开存储日志和数据将 CommitLog 和 ConsumerQueue 存储在不同的磁盘上减少磁盘 I/O 的竞争。
清理过期消息
设置消息过期时间根据业务需求在 Broker 配置文件中设置消息过期时间默认是72小时。过期的消息会被定期清理释放存储空间。手动清理在必要时可以手动清理过期消息确保存储空间的充足。
3. 性能优化
批量发送
批量发送配置在 Producer 端配置批量发送减少网络 I/O 次数。例如可以通过 sendBatchMessage 方法发送批量消息提高发送效率。批量大小控制合理设置批量消息的大小避免单次发送的数据量过大导致网络拥堵。
消费端并发
并发消费在 Consumer 端设置合理的并发线程数以提高消息的消费能力。可以通过 consumeThreadMin 和 consumeThreadMax 参数来调整消费线程数。顺序消费对于需要保证顺序的消息使用顺序消费模式Orderly避免消息乱序。
异步发送与回调
异步发送使用异步发送方式通过 sendAsync 方法发送消息避免同步等待提高发送性能。回调处理结合回调函数处理发送结果及时处理发送失败的情况。
4. 消息重试和补偿
消息重试机制
消费重试利用 RocketMQ 内置的重试机制确保消息消费成功。可以通过 maxReconsumeTimes 参数设置最大重试次数。重试间隔合理设置重试间隔避免频繁重试导致的资源浪费。
业务补偿机制
幂等性设计在关键业务场景中设计幂等性操作确保多次处理同一消息不会产生副作用。补偿事务对于分布式事务场景设计补偿机制确保事务的一致性。
5. 监控和报警
系统监控
RocketMQ Console使用 RocketMQ Console 监控系统的运行状态包括 Broker、Producer 和 Consumer 的状态。Prometheus 和 Grafana将 RocketMQ 的监控数据导入 Prometheus并使用 Grafana 可视化监控数据。
日志记录
详细日志启用详细的日志记录功能记录消息的发送、接收和消费的详细信息。可以通过调整 logLevel 参数设置日志级别。日志轮转定期轮转日志文件避免日志文件过大影响系统性能。
报警设置
阈值报警设置合理的报警阈值当系统指标如消息堆积、发送失败率等超过阈值时触发报警。邮件和短信通知配置报警通知通过邮件和短信及时通知运维人员进行处理。
6. 安全性
权限控制
ACL 配置启用 RocketMQ 的访问控制列表ACL功能对 Producer 和 Consumer 进行权限管理防止非法访问。可以在配置文件中设置 ACL 规则。用户认证对接入 RocketMQ 的用户进行认证确保只有合法用户才能访问消息系统。
数据加密
传输加密对消息传输过程进行加密使用 SSL/TLS 协议保护数据的安全。存储加密对敏感数据进行加密存储确保数据在磁盘上的安全。
网络隔离
内网部署将 RocketMQ 部署在内网环境中通过防火墙和 VPN 等手段进行网络隔离防止外部攻击。IP 白名单配置 IP 白名单只允许特定 IP 地址访问 RocketMQ 服务。
7. 灾备和容灾
跨地域部署
多地域部署在多个地域部署 Broker 集群确保在一个地域发生故障时能够自动切换到其他地域继续提供服务。数据同步利用 RocketMQ 的数据同步功能在不同地域之间进行数据同步确保数据的一致性。
数据备份
定期备份定期进行数据备份确保在发生数据丢失时能够快速恢复数据。可以通过定期备份 CommitLog 和 ConsumerQueue 数据来实现。异地备份将备份数据存储在异地防止同一地点的灾难导致备份数据丢失。
总结
通过遵循以上详细的最佳实践可以有效提升 RocketMQ 的稳定性、性能和安全性确保消息系统能够高效、可靠地运行。结合具体的业务需求和系统环境合理配置和优化 RocketMQ可以实现最佳的使用效果。
九、Go语言实践RocketMQ样例
在 Go 语言中使用 RocketMQ你需要使用 RocketMQ 的 Go 客户端库来进行消息的生产和消费。下面是一个简单的实践示例包括如何配置 RocketMQ Go 客户端、发送消息和消费消息的步骤。
1. 安装 RocketMQ Go 客户端库
首先你需要安装 RocketMQ 的 Go 客户端库。可以通过 Go 的包管理工具 go get 来安装
go get github.com/apache/rocketmq-client-go/v22. 发送消息
以下是一个简单的 Go 语言程序用于向 RocketMQ 发送消息
package mainimport (fmtloggithub.com/apache/rocketmq-client-go/v2/producergithub.com/apache/rocketmq-client-go/v2/primitive
)func main() {// 创建一个 RocketMQ 生产者实例p, err : producer.NewProducer(producer.WithNameServer([]string{localhost:9876}))if err ! nil {log.Fatalf(create producer failed: %s, err.Error())}// 启动生产者err p.Start()if err ! nil {log.Fatalf(start producer failed: %s, err.Error())}defer p.Shutdown()// 创建消息msg : primitive.Message{Topic: TestTopic,Body: []byte(Hello RocketMQ!),}// 发送消息res, err : p.SendSync(context.Background(), msg)if err ! nil {log.Fatalf(send message failed: %s, err.Error())}fmt.Printf(Send message success: %s\n, res.String())
}3. 接收消息
以下是一个简单的 Go 语言程序用于从 RocketMQ 消费消息
package mainimport (contextfmtloggithub.com/apache/rocketmq-client-go/v2/consumergithub.com/apache/rocketmq-client-go/v2/primitive
)func main() {// 创建一个 RocketMQ 消费者实例c, err : consumer.NewPushConsumer(consumer.WithNameServer([]string{localhost:9876}),consumer.WithGroupName(TestConsumerGroup),)if err ! nil {log.Fatalf(create consumer failed: %s, err.Error())}// 定义消息处理函数c.RegisterMessageListener(consumer.MessageListenerFunc(func(ctx context.Context, msgs ...*primitive.MessageExt) (consumer.ConsumeResult, error) {for _, msg : range msgs {fmt.Printf(Received message: %s\n, string(msg.Body))}return consumer.ConsumeSuccess, nil}))// 订阅主题err c.Subscribe(TestTopic, consumer.MessageSelector{}, nil)if err ! nil {log.Fatalf(subscribe topic failed: %s, err.Error())}// 启动消费者err c.Start()if err ! nil {log.Fatalf(start consumer failed: %s, err.Error())}defer c.Shutdown()// 阻塞主线程保持消费者运行select {}
}4. 运行示例 确保你已经启动了 RocketMQ 服务并且 localhost:9876 是你的 NameServer 地址。 编译并运行发送消息程序 go run producer.go编译并运行接收消息程序 go run consumer.go你应该能看到发送的消息被消费者接收到并输出。
注意事项
NameServer 地址确保你在创建生产者和消费者时指定的 NameServer 地址是正确的并且 RocketMQ 服务正在运行。主题和消费者组确保在 RocketMQ 中已经创建了相应的主题Topic并且消费者组Consumer Group设置正确。错误处理在生产环境中你应该实现更详细的错误处理和日志记录以便调试和监控。
以上就是如何在 Go 语言中实践 RocketMQ 的基本步骤。
十、RocketMQ历史演进
RocketMQ 是一个高性能、高可用的分布式消息中间件最初由阿里巴巴开源并在社区中逐渐发展和演进。以下是 RocketMQ 的主要历史演进过程
1. 初始版本 (2012-2015) 2012年RocketMQ 的前身被阿里巴巴开发为一个内部消息中间件用于支持大规模的电商平台和业务系统。 2013年阿里巴巴开始开源 RocketMQ最初以阿里巴巴内部的需求和经验为基础开发。早期版本主要用于阿里巴巴内部系统支持基本的消息队列功能。 2015年RocketMQ 被正式开源并成为 Apache 顶级项目。Apache RocketMQ 提供了更加成熟的消息中间件功能满足了高吞吐量、低延迟和高可靠性的需求。
2. 成为 Apache 顶级项目 (2016-2019) 2016年RocketMQ 成为 Apache 顶级项目标志着其在开源社区中的认可和稳定性。Apache RocketMQ 提供了生产环境所需的多种特性包括事务消息、消息过滤、消息顺序消费等。 2017年引入了支持多种语言的客户端 SDK包括 Java、C、Python 和 Go 等。 2018年引入了新的特性和改进包括改进的消息存储机制、增强的高可用性和容错能力、以及更多的管理和监控工具。 2019年发布了 RocketMQ 4.x 版本引入了更高的性能优化和新特性如消息轨迹Message Track、增强的客户端性能等。
3. 云原生和微服务支持 (2020-2023) 2020年RocketMQ 5.0 版本发布引入了云原生支持和对微服务架构的支持包括对 Kubernetes 的支持、集成了 Prometheus 监控、增强的分布式事务能力等。RocketMQ 5.0 还引入了新的存储引擎和更加灵活的消息路由策略。 2021年进一步改进了 RocketMQ 的高可用性、可扩展性和性能提供了更多的集群管理工具和性能监控功能。 2022年引入了 RocketMQ 5.1 版本改进了消息顺序消费的可靠性和性能同时增强了对云平台的支持优化了与大数据平台的集成能力。 2023年发布了 RocketMQ 5.2 版本增加了新的功能和改进包括更好的分布式事务支持、消息历史追踪功能和更高效的消息存储机制。
4. 未来发展
未来计划RocketMQ 继续关注云原生架构的演进、微服务架构的支持以及与其他大数据和流处理平台的集成。未来的版本可能会引入更多对多租户和弹性伸缩的支持以及对新的消息通信协议的支持。
总结
RocketMQ 从一个内部使用的消息中间件发展成为一个成熟的开源项目经过不断的改进和演进逐步成为 Apache 顶级项目并支持现代的云原生和微服务架构。通过持续的开发和社区贡献RocketMQ 不断适应新的技术需求和业务场景。
完。
希望对您有所帮助关注锅总及时获得更多花里胡哨的运维实用操作
十一、一个秘密 锅总个人博客
https://gentlewok.blog.csdn.net/
锅总微信公众号
