《RabbitMQ系列教程第一章消息中间件简介》

• 本系列教程目录大纲&＃xff1a;《RabbitMQ系列教程-目录大纲》

• 本系列教程配套代码&＃xff1a;https://gitee.com/lvshuichangliu/rabbitmt.git&＃xff08;码云地址&＃xff09;

1.1 概述

MQ全称为Message Queue&＃xff0c;消息队列是消息在传递过程中的容器&＃xff0c;消息队列常用于分布式系统之间的通信

消息队列中间件是分布式系统中重要的组件&＃xff0c;主要解决应用耦合&＃xff0c;异步消息&＃xff0c;流量削锋等问题实现高性能&＃xff0c;高可用&＃xff0c;可伸缩和最终一致性架构&＃xff1b;使用较多的消息队列有ActiveMQ&＃xff0c;RabbitMQ&＃xff0c;ZeroMQ&＃xff0c;Kafka&＃xff0c;MetaMQ&＃xff0c;RocketMQ以下介绍消息队列在实际应用中常用的使用场景&＃xff1a;异步处理&＃xff0c;应用解耦&＃xff0c;流量削锋和消息通讯四个场景

1.2 消息中间件的好处

在项目中&＃xff0c;可将一些无需即时返回且耗时的操作提取出来&＃xff0c;进行异步处理&＃xff0c;而这种异步处理的方式大大的节省了服务器的请求响应时间&＃xff0c;从而提高了系统的吞吐量。

1.2.1 应用解耦

在我们的应用中&＃xff0c;下订单同时需要调用库存系统、支付系统等业务&＃xff1b;

随着业务升级&＃xff0c;需要更改业务需求&＃xff0c;在下订单的同时需要对接积分系统进行加积分操作&＃xff0c;因此结果变为如下&＃xff1a;

从上图的演变我们可以知道&＃xff0c;随着业务的不断升级&＃xff0c;业务的不多增加&＃xff0c;我们可能需要频繁的修改订单系统的代码&＃xff0c;现在我们的订单系统严重和其他系统耦合在一起了&＃xff0c;可维护差&＃xff1b;不仅如此&＃xff0c;当订单系统调用库存系统时&＃xff0c;如果库存系统不能够及时响应&＃xff0c;那么必定会造成订单系统的延迟&＃xff0c;或者库存系统出现错误&＃xff0c;那么也很有可能导致订单系统出现故障&＃xff0c;系统的容错性非常低&＃xff1b;

为了解决上述问题&＃xff0c;我们引入了消息中间件&＃xff08;MQ&＃xff09;&＃xff1a;

当订单系统需要对接其他系统时&＃xff0c;只需要发消息给MQ&＃xff0c;由MQ来通知其他系统进行业务操作&＃xff0c;订单系统只与MQ进行对接&＃xff0c;从而解决我们上面的几个问题&＃xff1b;

• 1&＃xff09;业务耦合

• 2&＃xff09;系统延迟

• 3&＃xff09;容错性低

1.2.2 异步处理

在我们没有引入MQ之前的老系统中&＃xff0c;调用订单系统&＃xff0c;等待订单系统处理完业务逻辑之后响应客户端大概需要时间&＃xff1a;200ms&＃43;200ms&＃43;200ms&＃61;600ms

引入了MQ队列之后只需要5ms&＃xff01;

这里说明一点&＃xff1a;我们之前讲MQ概述时已经讲过&＃xff0c;MQ适用于一些无需即时返回且耗时的操作&＃xff0c;假设在上述架构中&＃xff0c;订单系统需要库存系统返回某值后才能进行下一步操作则不适用于MQ

1.2.3 流量削峰

流量削峰指的是在应用服务器面对大流量访问时&＃xff0c;MQ可以帮助我们进行流量的限流操作&＃xff0c;削弱流量&＃xff0c;保证服务器的正常运行&＃xff1b;

假设现在某电商网站搞促销活动&＃xff0c;导致流量迅速激增&＃xff0c;已经远远超过应用服务器的压力承受范围&＃xff0c;此时如果不进行流量&＃xff08;QPS&＃xff09;的控制&＃xff0c;那么应用服务器很有可能会出现故障&＃xff1a;

为了防止过度的流量同时进入我们的应用服务器&＃xff0c;导致应用服务器最终宕机&＃xff0c;我们可以进行限流手段&＃xff0c;即每秒从MQ中拉取1000个请求进行处理&＃xff1a;

由于高并发的访问&＃xff0c;消息会被挤压在MQ中&＃xff0c;在高峰期过后&＃xff0c;仍有一段时间内消息消费的速度维护在1000/s&＃xff0c;直到挤压的消息全部被消费完毕&＃xff1b;

1.3 消息中间件带来的问题

1.3.1 消息一致性

如上图&＃xff0c;如果订单系统给其他系统发送完毕消息后&＃xff0c;某个系统处理失败&＃xff0c;该如何保证数据的一致性&＃xff1f;

1.3.2 消息重复消费&＃xff08;消息幂等性&＃xff09;

当我们一个接口多次消费一个消息时&＃xff0c;我们需要保证这个操作无论被操作多少次其结果是一样的&＃xff0c;这个时候我们就需要保证接口的幂等性&＃xff1b;

幂等&＃xff1a;一个操作任意执行多次与执行一次的结果是相同的

在上述系统中&＃xff0c;如果执行库存系统出现问题&＃xff0c;那么订单系统会重发消息&＃xff0c;但是支付和积分系统是没有任何问题的&＃xff0c;但由于消息的重发&＃xff0c;导致支付和积分系统再次消费一次消息&＃xff1b;

1.3.3 成本问题

• 系统可用性降低

系统引入的外部依赖越多&＃xff0c;系统稳定性越差。一旦 MQ 宕机&＃xff0c;就会对业务造成影响。如何保证MQ的高可用&＃xff1f;

• 系统复杂度提高

MQ 的加入大大增加了系统的复杂度&＃xff0c;以前系统间是同步的远程调用&＃xff0c;现在是通过 MQ 进行异步调用。需要保证MQ带来的一系列问题

1.3 常见MQ性能对比

1.4 AMQP和JMS

• AMQP&＃xff1a;即Advanced Message Queuing Protocol&＃xff0c;一个提供统一消息服务的应用层标准高级消息队列协议&＃xff0c;是应用层协议的一个开放标准&＃xff0c;为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息&＃xff0c;并不受客户端中间件不同产品的限制&＃xff0c;不同的开发语言等条件的限制。Erlang中的实现有RabbitMQ等。

• JMS&＃xff1a;JMS即Java消息服务&＃xff08;Java Message Service&＃xff09;应用程序接口&＃xff0c;是一个Java平台中关于面向消息中间件&＃xff08;MOM&＃xff09;的API&＃xff0c;用于在两个应用程序之间&＃xff0c;或分布式系统中发送消息&＃xff0c;进行异步通信。Java消息服务是一个与具体平台无关的API&＃xff0c;绝大多数消息中间件提供商都对JMS提供支持。

AMQP是基于消息传输的一个应用层协议&＃xff0c;JMS准确的来说是Java操作MQ的一套API&＃xff0c;类似于JDBC&＃xff0c;第三方厂商&＃xff08;MySQL厂商、MQ厂商&＃xff09;进行功能的实现&＃xff0c;Java则使用JMS对厂商进行规范&＃xff1b;

下一篇&＃xff1a;RabbitMQ系列教程-第二章-RabbitMQ简介