【RocketMQ】MQ与RocketMQ介绍

🎯 导读：本文介绍了消息队列（MQ）的基本概念及其在分布式系统中的作用，包括实现异步通信、削峰限流和应用解耦等方面的优势，并对ActiveMQ、RabbitMQ、RocketMQ及Kafka四种MQ产品进行了对比分析，涵盖了它们的开发语言、吞吐量、时效性和可用性等特点。此外，文章还特别介绍了RocketMQ，包括其架构设计、高可用性实现方式以及消费模式等内容，突出了RocketMQ在消息顺序消费、拉取模式、扩展性等方面的优势。

文章目录

MQ简介
- MQ定义
- MQ作用
- - `作用一：异步`
  - `作用二：削峰限流`
  - `作用三：解耦`
- 为什么要使用MQ
- MQ使用流程
- - 实际业务
不同 MQ 产品对比
RocketMQ简介
- 相关重要概念
- RocketMQ为何高可用
- Broker内部结构
- 生产和消费理解
- 消费模式

MQ简介

MQ即Message Queue

Message消息：消息可以是一句话、一个短信、一份邮件、一份业务数据
Queue队列：用来存放消息
生产者将消息发送到队列中，消费者到队列中获取消息进行消费

MQ定义

MQ是一个消息中间件（如缓存中间件有redis、memcache；数据库中间件有mycat、canal）
利用高效可靠的消息传递机制进行与平台无关（跨平台）的数据交流，并基于数据通信来进行分布式系统的集成。
通过提供消息传递和消息排队模型在分布式环境下提供应用解耦，弹性伸缩，冗余存储，流量削峰，异步通信，数据同步等

MQ作用

为什么要用消息队列来存储消息，生产者为什么不直接发给消费者？

`作用一：异步`

生产者发给消费者，消费者在忙其他事，当前没时间处理，咋办？生产者等着吗，显然不合理。使用异步的方式，生产者发完消息之后，就去做自己的事情，后续消费者有空再去队列中获取数据来执行业务即可；

案例：假如系统 A 希望发送一个消息给系统 B 去处理，但系统 A 不关注系统 B 到底怎么处理或者有没有处理完，系统 A 把消息发送给 MQ ，就不管这条消息的死活了，接着系统 B 从MQ里面消费出来处理即可。至于怎么处理，是否处理完毕，什么时候处理，都是系统 B 的事，与系统 A 无关。

在这里插入图片描述

这样的一种通信方式，就是所谓的“异步”通信方式，对于系统A来说，只要把消息发给MQ，然后系统B就会异步处去进行处理了，系统A不需要“同步”的等待系统B处理完。这样的好处是什么呢？解耦

`作用二：削峰限流`

消费者的业务执行能力是有限的，例如一个业务执行需要花费3秒。假如大量请求同时过来，tomcat线程池的线程被占用完了，后续的请求会报错（503服务不可用）。如果请求过来之后，直接放到消息队列就返回，这样就可以大大降低服务不可用的概率，后续消费者再去消息队列里面慢慢获取业务信息去执行即可；

`作用三：解耦`

取消应用之间、模块之间的强耦合关系，让程序更加健壮、高可用。如果模块都直接耦合在一块，一个模块出问题，很容易影响到其他模块。通过使用A模块->消息队列->B模块模式将A、B模块解耦

【应用系统解耦的好处】

发送者和接收者不必了解对方，只需要确认消息
发送者和接收者不必同时在线

为什么要使用MQ

1、做系统解耦，当新的模块进来时，可以做到代码改动最小; 解耦

2、让后端系统按自身吞吐能力进行消费，不被瞬时流量冲垮; 削峰限流

3、通过强弱依赖梳理，把非关键调用链路的操作异步化，提升整体系统的吞吐能力; 异步处理

MQ使用流程

发送者把消息发给消息服务器，消息服务器把消息存放在若干队列/主题中，在合适的时候，消息服务器会把消息转发给接收者。在这个过程中，发送和接受是异步的，发送无需等待，发送者和接受者的生命周期没有必然关系。
在发布pub/订阅sub模式下，也可以完成一对多的通信，即让一个消息有多个接受者（例如微信订阅号）

在这里插入图片描述

实际业务

在这里插入图片描述

不同 MQ 产品对比

MQ主要关注两个性能：

吞吐量：单位时间内可以处理多少条消息（用消息大小来描述更准确，因为消息内存越小，数量会越大）
时效性：生产者发消息，MQ多久才收到消息

【对比】

特性	ActiveMQ	RabbitMQ	Rocket MQ	kafka
开发语言	java	erlang	java	scala
单机吞吐量	万级	万级	10万级	10万级
时效性	ms级	us级	ms级	ms级以内
可用性	高(主从架构)	高(主从架构)	非常高(分布式架构)	非常高(分布式架构)
功能特性	成熟的产品，在很多公司得到应用；有较多的文档；各种协议支持较好	基于Erlang开发，所以并发能力很强，性能极其好，延时很低;管理界面较丰富	MQ功能比较完备，扩展性佳	只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广。

【总结】

activeMQ：使用java实现(jms 协议)，性能一般，出现早，功能单一，吞吐量低
rabbitmq：使用erlang实现(amqp 协议)，性能好，功能丰富，吞吐量一般
rocketmq：使用java实现，性能好，功能最丰富，吞吐量高
kafka：使用scala实现，吞吐量最大，功能单一（专注读、写），主要用于大数据领域（数据又多又大）

RocketMQ简介

官网： http://rocketmq.apache.org/

在这里插入图片描述

RocketMQ是阿里巴巴2016年MQ中间件，使用Java语言开发，是一款开源的分布式消息系统（可以做集群），基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。同时，广泛应用于多个领域，包括异步通信解耦、企业解决方案、金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、移动应用、手游、视频、物联网、车联网等。

具有以下特点：

能够严格保证消息按照顺序消费
提供丰富的消息拉取模式
高效的订阅者水平扩展能力
实时的消息订阅机制
亿级消息堆积能力

RocketMQ为何高可用

如何设计高可用消息队列？

光是这样设置，不是高可用的，一旦broker挂了，业务就中断

在这里插入图片描述

使用broker集群实现写的高可用

在这里插入图片描述

使用主从同步实现读的高可用。读可以去主节点读，也可以去从节点读（负载均衡）

在这里插入图片描述

Broker内部结构

一个Broker里面可以存放多个Topic，一个Topic里面可以存放多个队列

在这里插入图片描述

生产和消费理解

在这里插入图片描述

消费模式

MQ的消费模式可以大致分为两种

推 Push ：服务端【MQ】主动推送消息给客户端，优点是**及时性较好，**但如果客户端没有做好流控，一旦服务端推送大量消息到客户端时，就会导致客户端消息堆积甚至崩溃（客户端压力大）
拉 Pull ：客户端需要主动到服务端【MQ】拉取数据，优点是客户端可以依据自己的消费能力进行消费，拉取的频率需要用户自己控制（压力可控，可以一次性拉取一批数据，效率更高），拉取频繁容易造成服务端和客户端的网络传输压力，拉取间隔长又容易造成消费不及时（实时性不强）

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("test-consumer-group");
DefaultMQPushConsumer consumer = new DefaultMQPullConsumer("test-consumer-group");