【消息队列】消息中间件介绍

layout: post
title: 【消息队列】消息中间件介绍
date: 章于 2024-08-06 15:44:50 发布
author: 'zhangtao'
header-img: 'img/post-bg-2015.jpg'
catalog: false
tags:

• Java
• java
• spring boot
• 中间件
• rabbitmq
• activemq
• rocketmq
• kafka

目录

• 电商系统引发的思考
• • 实现支付业务时使用串行操作（同步）
  • 串行操作存在的问题
  • 根据上述的几个问题，在设计系统时可以明确要达到的目标
• 消息中间件【MQ（Message Queue）】
• 使用场景
• • 1.应用解耦
  • 2.异步提速
  • 3.流量削峰
  • • 举个栗子
  • 4. 服务没有强依赖，不担心级联失败问题
• MQ的优点和缺点
• • 优点
  • 缺点
• MQ的消息通讯模型
• • JMS
  • AMQP
• MQ常用协议
• • AMQP协议
  • MQTT协议
  • STOMP协议
  • XMPP协议
  • 其他基于TCP/IP自定义的协议
• MQ的通讯模式
• • 点对点通讯
  • 多点广播
  • 发布/订阅(Publish/Subscribe)模式
  • 集群(Cluster)
• 多线程异步和消息队列的区别
• • 作用不同
  • 结构不同
  • 使用场景不同
• 消息队列如何保证数据不丢失
• • 持久化存储
  • 确认机制
  • 重试机制
  • 高可用性
  • 数据备份
• 主流的MQ产品
• • ActiveMQ
  • • 使用场景
    • 优点
    • 缺点
  • RabbitMQ
  • • 优点
    • 缺点
  • RocketMQ
  • • 优点
    • 缺点
  • Kafka
  • • 优点:
    • 缺点
  • 面试题：kafka、activemq、rabbitmq、rocketmq有什么优缺点
• RabbitMQ的组成部分
• • Broker
  • Virtual Host
  • Exchange
  • Queue
  • Binding
  • Connection
  • Channel
  • Producer
  • Consumer

{#_1}电商系统引发的思考

{#_2}实现支付业务时使用串行操作（同步）

{#_4}串行操作存在的问题

1. 耦合度高：每次加入新的需求，都要修改原来的代码
2. 性能下降：调用者需要等待服务提供者响应，如果调用链过长则响应时间等于每次调用的时间之和。
3. 资源浪费：调用链中的每个服务在等待响应过程中，不能释放请求占用的资源，高并发场景下会极度浪费系统资源
4. 级联失败：如果服务提供者出现问题，所有调用方都会跟着出问题，如同多米诺骨牌一样，迅速导致整个微服务群故障

{#_9}根据上述的几个问题，在设计系统时可以明确要达到的目标

• 要做到系统解耦，当新的模块接进来时，可以做到代码改动最小；能够解耦
• 设置流量缓冲池，可以让后端系统按照自身吞吐能力进行消费，不被冲垮；能削峰
• 强弱依赖梳理，能将非关键调用链路的操作异步化并提升整体系统的吞吐能力；

MQ可以解决以上问题

{#MQMessage_Queue_16}消息中间件【MQ（Message Queue）】

{#1_27}1.应用解耦

• 一个业务需要多个模块共同实现，或者一条消息有多个系统需要对应处理，只需要主业务完成以后，发送一条MQ，其余模块消费MQ消息，即可实现业务，降低模块之间的耦合。
  

{#2_30}2.异步提速

• 性能提升，吞吐量提高，主业务执行结束后从属业务通过MQ，异步执行，减低业务的响应时间，提高用户体验。
  

{#3_33}3.流量削峰

• 高并发情况下，业务异步处理，提供高峰期业务处理能力，避免系统瘫痪。

{#_35}举个栗子

• 如果订单系统最多能处理一万次订单，这个处理能力应付正常时段的下单时绰绰有余，正常时段我们下单一秒后就能返回结果。
• 但是在高峰期，如果有两万次下单操作系统是处理不了的，只能限制订单超过一万后不允许用户下单。
• 使用消息队列做缓冲，我们可以取消这个限制，把一秒内下的订单分散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好。

{#4__41}4. 服务没有强依赖，不担心级联失败问题

{#MQ_44}MQ的优点和缺点

• MQ的消息通信模型：实现MQ的大致有两种主流方式：JMS、AMQP

{#JMS_56}JMS

• JMS即Java消息服务（JavaMessage Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间或分布式系统中发送消息，进行异步通信。
• JMS限定了必须使用Java语言。 JMS是定义了统一的接口，来对消息操作进行统一；

{#AMQP_59}AMQP

• AMQP是高级消息队列协议，是一个进程间传递异步消息的网络协议，更准确的说是一种binary wire-level protocol（链接协议）。这是其和JMS的本质差别，AMQP不从API层进行限定，而是直接定义网络交换的数据格式。
• AMQP只是协议，不规定实现方式，因此是跨语言的。

{#MQ_62}MQ常用协议

{#AMQP_63}AMQP协议

• AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。
• 优点：可靠、通用

{#MQTT_67}MQTT协议

• MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。
• 优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

{#STOMP_71}STOMP协议

• STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。
• 优点：命令模式（非topic/queue模式）

{#XMPP_75}XMPP协议

XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。

• 优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大

{#TCPIP_79}其他基于TCP/IP自定义的协议

• 有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。

{#MQ_81}MQ的通讯模式

{#ActiveMQ_131}ActiveMQ

• ActiveMQ 是Apache出品，功能强大的即时通讯和集成模式的开源服务器。
• ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。

{#_134}使用场景

ActiveMQ 采用消息推送方式，所以最适合的场景是默认消息都可在短时间内被消费。数据量越大，查找和消费消息就越慢，消息积压程度与消息速度成反比。

{#_136}优点

• 非常成熟，功能强大，在业内大量的公司以及项目中都有应用

{#_138}缺点

• 官方社区现在对 ActiveMQ 5.x 维护越来越少。
• 偶尔会有较低概率丢失消息。
• 而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用

{#RabbitMQ_142}RabbitMQ

• 2007 年发布，是一个在 AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
• 社区：https://www.rabbitmq.com/news.html

{#_145}优点

• 由于 erlang 语言的高并发特性，性能较好；吞吐量到万级
• MQ 功能比较完备,健壮、稳定、易用、跨平台、支持多种语言 如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持 AJAX 文档齐全；
• 开源提供的管理界面非常棒，用起来很好用社区相对比较活跃，几乎每个月都发布几个版本；
• 更新频率相当高；
• 事务性好，常应用于金融领域的事务控制
  

{#_153}缺点

• 商业版需要收费,学习成本较高
• RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。
• 而且erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话确实偶尔会有一些问题，你公司对这个东西的掌控很弱，基本只能依赖于开源社区的快速维护和修复bug。
• 而且rabbitMQ集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控

{#RocketMQ_158}RocketMQ

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

{#_160}优点

• 接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障

• 日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便

• 消息可以做到 0 丢失,MQ 功能较为完善，还是分布式的，扩展性好

• 支持 10 亿级别的消息堆积，不会因为堆积导致性能下降

• 还可以支持大规模的topic数量，支持复杂MQ场景。

• 而且一个很大的优势在于，阿里出品都是java系的，我们可以自己阅读源码，定制自己公司的MQ，可以掌控

• 补充：社区活跃度相对一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的，有些系统迁移要修改大量代码。还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的

{#_169}缺点

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

{#Kafka_172}Kafka

• 大数据的杀手锏，谈到大数据领域内的消息传输，则绕不开 Kafka，这款为大数据而生的消息中间件，以其百万级 TPS 的吞吐量名声大噪，迅速成为大数据领域的宠儿，在数据采集、传输、存储的过程中发挥着举足轻重的作用。

{#_174}优点:

• 性能卓越，单机写入 TPS 约在百万条/秒，最大的优点，就是吞吐量高。
• 时效性 ms 级可用性非常高，kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用,
• 消费者采用 Pull 方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
• 有优秀的第三方Kafka Web 管理界面 Kafka-Manager；在日志领域比较成熟。
• 同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量

{#_180}缺点

• Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息响应时间变长
• 使用短轮询方式，实时性取决于轮询间隔时间，消费失败不支持重试；
• 支持消息顺序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢
• 有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略。这个特性天然适合大数据实时计算以及日志收集

{#kafkaactivemqrabbitmqrocketmq_185}面试题：kafka、activemq、rabbitmq、rocketmq有什么优缺点

| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|:--|:-|:-

{#Broker_203}Broker

• 接收和分发消息的应用，消息队列服务进程，此进程包括两个部分：Exchange和Queue。
• RabbitMQ Server就是Message Broker。

{#Virtual_Host_206}Virtual Host

• 虚拟主机，用于逻辑隔离。
• 一个虚拟主机里面可以有若干个Exchange和Queue，同一个虚拟主机里面不能有相同名称的Exchange或Queue。

{#Exchange_209}Exchange

• 消息交换机，作用是接收来自生产者的消息，并根据路由键转发消息到所绑定的队列。

{#Queue_211}Queue

• 即队列，RabbitMQ内部用于存储消息的对象，是真正用存储消息的结构，在生产端，生产者的消息最终发送到指定队列，而消费者也是通过订阅某个队列，达到获取消息的目的。

{#Binding_213}Binding

• Binding是一种操作，其作用是建立消息从Exchange转发到Queue的规则
• 在进行Exchange与Queue的绑定时，需要指定一个BindingKey
• Binding操作一般用于RabbitMQ的路由工作模式和主题工作模式。

{#Connection_217}Connection

• Connection就是一个TCP的连接，Producer和Consumer都是通过TCP连接到RabbitMQ Server的。

{#Channel_219}Channel

• 信道，多路复用连接中的一条独立的双向数据流通道。
• 是建立在上述的TCP连接中，因为建立TCP Connection的开销将是巨大的，所以其是为了节省Rabbitmq开销。

{#Producer_222}Producer

• 消息生产者，即生产方客户端，生产方客户端将消息发送

{#Consumer_224}Consumer

• 消息消费者，即消费方客户端，接收MQ转发的消息

原文链接: https://zhoujl.blog.csdn.net//article/details/138575288