本文主要是介绍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 架构介绍的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!