消息队列之RocketMQ学习记录（一）

目录

什么是消息队列

为什么要用消息队列

解耦

异步

削峰 

为什么选择RocketMQ

RocketMQ架构原理 

---

什么是消息队列

Message Queue就是消息队列，定义是在消息的传输过程中保存消息的容器。

为什么要用消息队列

解耦

当一个服务与其他多个服务相互调用的时候，如果采取耦合在一起的方式，那么一旦提供服务的一方需要改动代码或其他，那么其他服务都会受到影响。例如平时购买商品，下单时候调用的是商家的订单系统，当然购买流程不仅仅是下单就结束的。订单系统处理完后就会去调用例如库存系统、物流系统等等处理。解耦就是用户提交订单后，利用消息队列去通知或调用库存、物流系统。

异步

继续上文的例子，如果没有用到消息队列的时候。整个流程大致为订单系统处理—库存系统处理—物流系统处理—返回结果。等于整个流程是同步执行的，像一条链子顺序执行。如果采用消息队列，那么就可以异步处理。

削峰 

削峰这个概念就是把暴增的流量削减到服务器可以承受的范围，例如下图是秒杀活动时的处理流程。服务器与用户之前多了一层MQ，因为MQ性能极好，一般能抗到10万并发量，假如本服务器能承受1000QPS，这时候1万人来秒杀的话服务器肯定直接就挂了。如果流量先打到MQ上，然后再以每秒1000的数量分给服务器，这样的过程就成为削峰。

为什么选择RocketMQ

我个人选择的原因就是RocketMQ是阿里系的产品，国内应用都很多，性能也很优秀。关于与其他消息队列的比较等这里就不多展开，感兴趣的可以了解下官方关于RocketMQ的选择原因http://rocketmq.apache.org/docs/motivation/

RocketMQ架构原理 

 

如上图是RocketMQ的物理架构，有四大核心部分

• Producer
• Consumer
• Broker
• NameServer

Producer，生产者，负责产生消息。有三种方法发送消息：同步、异步和单向

• 同步发送：同步发送指消息发送方发出数据后会在收到接收方发回响应之后才发下一个数据包。一般用于重要通知消息，例如重要通知邮件、营销短信。

• 异步发送：异步发送指发送方发出数据后，不等接收方发回响应，接着发送下个数据包，一般用于可能链路耗时较长而对响应时间敏感的业务场景，例如用户视频上传后通知启动转码服务。

• 单向发送：单向发送是指只负责发送消息而不等待服务器回应且没有回调函数触发，适用于某些耗时非常短但对可靠性要求并不高的场景，例如日志收集。

 Consumer，消费者，有Pull和Push两种方式

• Pull：拉取型消费者（Pull Consumer）主动从消息服务器拉取信息，只要批量拉取到消息，用户应用就会启动消费过程，所以 Pull 称为主动消费型

• Push：推送型消费者（Push Consumer）封装了消息的拉取、消费进度和其他的内部维护工作，将消息到达时执行的回调接口留给用户应用程序来实现。所以 Push 称为被动消费类型，但从实现上看还是从消息服务器中拉取消息，不同于 Pull 的是 Push 首先要注册消费监听器，当监听器处触发后才开始消费消息

Broker，是每台机器上部署的RocketMQ进程

• Broker是具体提供业务的服务器，单个Broker节点与所有的NameServer节点保持长连接及心跳，并会定时将Topic信息注册到NameServer。
• Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型。
• Broker通过主从架构和多副本策略实现高可用

NameServer，主要功能是为整个MQ集群提供服务协调与治理，具体就是记录维护Topic、Broker的信息，及监控Broker的运行状态。

• NameServer是集群化部署，这样一旦其中一台宕机，其他的机器上的NameServer可以继续提供服务
• 每个Broker都会向所有的NameServer进行注册
• 如果Broker超过120秒没有给NameServer发送心跳，此时NameServer就会认为Broker已经挂掉