本文主要是介绍Rocket MQ 架构介绍，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
文章目录
- 为什么选择Rocket MQ
- 基本概念
- 优点
- 缺点
- 架构图
- 编程模型
- 发送者发送消息固定步骤
- 消费者消费消息固定步骤
为什么选择Rocket MQ
Rocket MQ是阿帕奇顶级的开源项目，由阿里开发并开源。它的研发背景是Active MQ与Kafka不能很好的解决当时的业务场景。官网上是这么描述的：
在阿里孕育 RocketMQ 的雏形时期，我们将其用于异步通信、搜索、社交网络活动流、数据管道，贸易流程中。随着我们的贸易业务吞吐量
的上升，源自我们的消息传递集群的压力也变得紧迫。根据我们的研究，随着队列和虚拟主题使用的增加，ActiveMQ IO模块达到了一个瓶颈。我们尽力通过节流、断路器或降级来解决这个问题，
但效果并不理想。于是我们尝试了流行的消息传递解决方案Kafka。不幸的是，Kafka不能满足我们的要求，其尤其表现在低延迟和高可靠性
方面，详见下文。在这种情况下，我们决定发明一个新的消息传递引擎来处理更广泛的消息用例，覆盖从传统的pub/sub场景到高容量的实时
零误差的交易系统。
基本概念
| 名词 | 描述 |
|---|---|
| Producer（生产者） | 消息的生产者，一般是系统中的一个功能模块 |
| Consumer（消费者） | 消息的消费者，一般是系统中的一个功能模块 |
| Name server 命名空间 | 用于维护Broker与Topic的信息，提供轻量级的Broker路由服务 |
| Broker | 实际处理消息存储、转发等服务的核心组件 |
| Topic | 区分消息的种类，用于路由消息 |
| Message Queqe | Topic的分区，用于并行发送和接收消息 |
优点
- 异步：可以提高系统的响应速度，吞吐量。比如现在的菜鸟驿站/快递柜，快递员只需把快递送到驿站/快递柜即可送下一个快递，不用等A客户拿到快递后，再去给B客户拿快递。
- 解耦：快递员是一个独立的角色，负责派送包裹，而不需要直接与收件人进行实时交互。快递员可以通过查询系统或从调度中心获取待派送的包裹信息，然后根据包裹上的地址信息进行派送。
- 削峰：超市618，双十一都会有大促活动。超市可以采用分时段入场、预约购物或提前安排活动等措施，将顾客的到达时间分散在更长的时间段内，从而减少高峰时段的拥堵和排队等待时间。
缺点
- 系统稳定性降低：引入新的外部依赖，对系统稳定性有影响，如果MQ宕机不可用，会导致整个系统不可用
- 系统复杂度变高：MQ是异步的，需要考虑消息如何不丢失？消息不重复消费？如何保证顺序消费等
- 数据一致性问题：假设A系统发出消息，B，C两个系统来消费。B消费成功，C消费失败，此时如何处理？
架构图
编程模型
发送者发送消息固定步骤
- 创建producer，确定生产者组名
- 指定name server地址
- 启动producer
- 创建消息对象，指定主题topic，tag和消息体
- 发送消息
- 关闭producer
消费者消费消息固定步骤
- 创建消费者Consumer，确定消费者组名
- 指定name server地址
- 订阅主题topic 和 tag
- 设置回调函数，处理消息
- 启动消费者consumer
这篇关于Rocket MQ 架构介绍的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
