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消费失败，此时如何处理？

架构图

编程模型

发送者发送消息固定步骤

1. 创建producer，确定生产者组名
2. 指定name server地址
3. 启动producer
4. 创建消息对象，指定主题topic，tag和消息体
5. 发送消息
6. 关闭producer

消费者消费消息固定步骤

1. 创建消费者Consumer，确定消费者组名
2. 指定name server地址
3. 订阅主题topic 和 tag
4. 设置回调函数，处理消息
5. 启动消费者consumer