1. 程序员快看-教程，程序员编程资料站
  2. 首页
  3. RabbitMQ基础
  4. 正文

01、RabbitMQ基础：概述

分类：RabbitMQ基础    2024-03-09    阅读(361)

有道无术，术尚可求，有术无道，止于术。

文章目录

    • 什么是MQ？
  • 核心功能
    • 1、流量削峰填谷
    • 2、应用解耦
    • 3、异步处理
  • 消息通信模型
    • JMS
      • P2P消息模型
      • 发布订阅模型
    • AMQP
  • 常用MQ
    • ActiveMQ
    • Kafka
    • RocketMQ
    • RabbitMQ
    • 选型对比

什么是MQ？

MQ是Message Queue消息队列的首字母缩写。是指把要传输的数据（消息）放在队列中，用队列机制来实现消息传递，生产者产生消息并把消息放入队列，然后由消费者去处理。消费者可以到指定队列拉取消息，或者订阅相应的队列，由MQ服务端给其推送消息。

一般用来解决应用解耦，异步消息，流量削峰等问题，实现高性能，高可用，可伸缩和最终一致性架构。

核心功能

1、流量削峰填谷

在当前互联网的业务场景下，比如商品秒杀，在较短时间内，瞬时涌入大量请求，这个时候系统资源可能会耗尽，造成服务器瘫痪。

可以使用消息队列来缓冲瞬时流量，通过一个队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去。

例如下图中，A系统每秒只能处理1000个请求，但是某个瞬时请求达到5000每秒，这个时候将导致A系统并发过高，甚至系统奔溃。
*
使用了MQ之后，限制消费消息的速度为1000每秒，这样一来，高峰期产生的数据势必会被积压在MQ中，高峰就被“削”掉了，但是因为消息积压，在高峰期过后的一段时间内，消费消息的速度还是会维持在1000每秒，直到消费完积压的消息，这就叫做“填谷”。
*

2、应用解耦

以电商应用为例，应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障，都会造成下单操作异常。

当转变成基于消息队列的方式后，系统间调用的问题会减少很多，比如物流系统因为发生故障，需要几分钟来修复。在这几分钟的时间里，物流系统要处理的内存被缓存在消息队列中，用户的下单操作可以正常完成。当物流系统恢复后，继续处理订单信息即可，中单用户感受不到物流系统的故障，提升系统的可用性。
*

3、异步处理

有些服务间调用是异步的，例如 A 调用 B，B 需要花费很长时间执行，但是 A 需要知道 B 什么时候可以执行完。

一般有两种方式，A 过一段时间去调用 B 的查询 api 查询。或者 A 提供一个回调接口， B 执行完之后调用 api 通知 A 服务。

这两种方式都不是很优雅，使用MQ，可以很方便解决这个问题，A 调用 B 服务后，只需要监听 B 处理完成的消息，当 B 处理完成后，会发送一条消息给 MQ，MQ 会将此消息转发给 A 服务。这样 A 服务既不用循环调用 B 的查询 api，也不用提供回调接口。同样B 服务也不用做这些操作。A 服务还能及时的得到异步处理成功的消息。
*

消息通信模型

MQ消息通信模型，主要实现方式分为两种：JMS和AMQP。

JMS

JMS即JAVA Message Service。是 Java 平台上有关面向消息中间件的技术规范，它便于消息系统中的 Java 应用程序进行消息交换，并且通过提供标准的产生、发送、接收消息的接口，简化企业应用的开发。

JMS提供了两种消息模型

  • Point-to-Point(P2P) ：点对点
  • Publish/Subscribe(Pub/Sub)： 发布/订阅
P2P消息模型

涉及概念:

  • 消息队列(Queue)
  • 发送者(Sender)
  • 接受者(Receiver)
  • 每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时

点对点模式消息将发送到一个队列，该队列的消息只能被一个消费者消费。

特点:

  • 每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
  • 发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列
  • 接收者在成功接收消息之后需向队列应答成功
发布订阅模型

多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。

涉及概念:

  • 主题（Topic）
  • 发布者（Publisher）
  • 订阅者（Subscriber）

特点:

  • 每个消息可以有多个消费者
  • 如果你希望发送的消息可以不被做任何处理、或者被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型

AMQP

AMQP全称为Advanced Message Queuing Protocol（高级消息队列协议）,是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。总而言之，是一个进程间传递异步消息的网络协议。

在2003年时被提出，最早用于解决金融领不同平台之间的消息传递交互问题，兼容JMS。

特性：

  • 独立于平台的底层消息传递协议。
  • 消费者驱动消息传递。
  • 跨语言和平台的互用性、属于底层协议。
  • 有5种交换类型direct,fanout,topic,headers,system。
  • 面向缓存的、可实现高性能、支持经典的消息队列，循环，存储和转发。
  • 支持长周期消息传递、支持事务（跨消息队列）

AMQP和JMS的主要区别：

  • AMQP不从API层进行限定，直接定义网络交换的数据格式，这使得实现了AMQP天然性就是跨平台。比如Java语言产生的消息，可以用其他语言比如python的进行消费。
  • AQMP可以用http来进行类比，不关心实现接口的语言，只要都按照相应的数据格式去发送报文请求，不同语言的client可以和不同语言的server进行通讯。
  • JMS消息类型：TextMessage/ObjectMessage/StreamMessage等
  • AMQP消息类型：Byte[]

常用MQ

ActiveMQ

官方文档

ActiveMQ是Apache开源，完全支持J2EE规范的消息中间件。

优点：单机吞吐量万级，时效性 ms 级，可用性高，基于主从架构实现高可用性，消息可靠性较低的概率丢失数据。

缺点：官方社区现在对 ActiveMQ 5.x 维护越来越少，高吞吐量场景较少使用。

Kafka

官方文档

官网介绍：Kafka是一个开源的分布式事件流平台（Event StreamingPlatform），被数千家公司用于高性能数据管道、流分析、数据集成和关键任务应用。

一般理解为一个分布式的基于发布/订阅模式的消息队列，主要应用于大数据实时处理领域。

优点：

  • 性能卓越，单机写入 TPS 约在百万条/秒，最大的优点，就是吞吐量高
  • 时效性毫秒级
  • 可用性非常高，kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用,消费者采用 Pull 方式获取消息,
  • 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次
  • 有优秀的第三方Kafka Web 管理界面 Kafka-Manager
  • 在日志领域比较成熟，被多家公司和多个开源项目使用
  • 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用

缺点：

RocketMQ

官方文档

RocketMQ 出自阿里巴巴的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。被阿里巴巴广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等场景。

优点：

  • 单机吞吐量十万级
  • 分布式架构，可用性非常高，消息可以做到 0 丢失
  • 支持 10 亿级别的消息堆积，不会因为堆积导致性能下降
  • 源码是 java 我们可以自己阅读源码，定制自己公司的 MQ

缺点：

  • 支持的客户端语言不多，目前是 java 及 c++，其中 c++不成熟
  • 社区活跃度一般
  • 没有在MQ核心中去实现 JMS 等接口,有些系统要迁移需要修改大量代码

RabbitMQ

官方文档

2007 年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

优点：

  • 由于 erlang 语言的高并发特性，性能较好；吞吐量到万级
  • MQ 功能比较完备
  • 跨平台、支持多种语言 如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等
  • 支持 AJAX
  • 文档齐全
  • 开源提供的管理界面非常棒，用起来很好用,社区活跃度高；更新频率相当高

优点：

  • 商业版需要收费
  • 学习成本较高

选型对比

*

版权声明：本文不是「本站」原创文章，版权归原作者所有 | 原文地址: