• RabbitMQ系列【1】概述


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

    什么是MQ

    MQMessage 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消息通信模型,主要实现方式分为两种:JMSAMQP

    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
    • 文档齐全
    • 开源提供的管理界面非常棒,用起来很好用,社区活跃度高;更新频率相当高

    优点

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

    选型对比

    在这里插入图片描述

  • 相关阅读:
    CopyOnWriteArrayList源码分析
    VXLAN基础
    [PaddleSpeech 原神] 音色克隆之胡桃
    Flask 学习-96.Flask-SQLAlchemy 判断查询结果是否存在的几种方式
    好的架构是进化来的,不是设计来的
    利用Python计算积分
    cookie以及Storage的共同点、区别与使用
    SLAM中的子图
    js的加载过程和文档解析过程
    一文看懂单总线协议(1-wire)
  • 原文地址:https://blog.csdn.net/qq_43437874/article/details/127003443