消息中间件小结_消息中间件怎么返回值-CSDN博客

本文链接：https://blog.csdn.net/u010397795/article/details/102502242

文章目录

消息中间件小结

消息中间件小结

消息中间件概述

什么是消息中间件

消息中间件，也可以叫做中央消息队列或者是消息队列（区别于本地消息队列，本地消息队列指的是JVM内的队列实现），是一种独立的队列系统，消息中间件经常用来解决内部服务之间的异步调用问题。请求服务方把请求队列放到队列中即可返回，然后等待服务提供方去队列中获取请求进行处理，之后通过回调等机制把结果返回给请求服务方。
消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流；并基于数据通信来进行分布式系统的集成；通过提供消息传递和消息排队模型，它可以在分布式环境下拓展进程间的通信。
常见的消息中间件有ActiveMQ、RabbitMQ、Kafka、RocketMQ。

消息中间件核心设计

本质

消息中间件其实是一种具备接受请求、保存数据、发送数据等功能的网络应用。消息中间件和一般网络应用程序的区别是它主要负责数据的接受和传递，所以性能一般都高于普通程序。

5大核心组成

1、协议
2、持久化机制
3、消息分发机制
4、高可用设计
5、高可靠设计

协议

消息中间件常用的协议：OpenWire、AMQP、MQTT、Kafka、OpenMessage。
AMQP协议：有事务支持、持久化支持，出生金融行业，在可靠性消息处理上具备天然的优势。
MQTT协议：轻量、结构简单、传输快、没有事务支持、没有持久化相关设计。适用于计算能力有限。低带宽、网络不稳定的场景。
Open Message协议：结构简单、解析快、有事务设计、有持久化设计。
Kafka协议：结构简单、解析快、无事务设计、有持久化设计。

持久化

持久化简单来说就是将数据存入磁盘，而不是存在内存中随服务重启而消失，使数据能够永久保存。

持久化方式	ActiveMQ	RabbitMQ	Kafka	RocketMQ
文件系统	支持	支持	支持	支持
数据库	支持	/	/	/

消息分发

消息分发策略	ActiveMQ	RabbitMQ	Kafka	RocketMQ
发布订阅	支持	支持	支持	支持
轮询分发	支持	支持	支持	/
轮询分发	支持	支持	支持	/
公平分发	/	支持	支持	/
重发	支持	支持	/	支持
消息拉取	/	支持	支持	支持

高可用

高可用性是指产品在规定的条件和规定的时刻或时间区间内处于可执行规定功能状态的能力。
当业务量大时，一台消息中间件服务器可能无法满足需求，所以需要消息中间件能够集群部署，来达到高可用的目的。集群部署的方案有Master-Slave主从共享数据的部署方式、Master-Slave主从同步部署方式、Broker-Cluster多主集群同步部署方式、Broker-Cluster多主集群转发部署方式、Master-Slave和Broker-Cluster结合。

高可靠

高可靠性是指系统可以无故障地持续运行。比如一个系统从来不崩溃、报错，或者崩溃、报错的几率较低，那就是高可靠。
保证消息中间件的高可靠性，可以从以下方面考虑。
消息传输可靠：通过协议来保证系统间数据解析的正确性。
消息存储可靠：通过持久化来保证消息的存储可靠性。

消息中间件的应用场景

削峰限流

在不使用消息队列服务器的时候，用户的请求数据直接写入数据库，在高并发的情况下数据库压力剧增，使得响应速度变慢。但是在使用消息队列之后，用户的请求数据发送给消息队列之后立即返回，再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。由于消息队列服务器处理速度快于数据库（消息队列也比数据库有更好的伸缩性），因此响应速度得到大幅改善。
通过以上分析我们可以得出消息队列具有很好的削峰作用的功能——即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。
因为用户请求数据写入消息队列之后就立即返回给用户了，但是请求数据在后续的业务校验、写数据库等操作中可能失败。因此使用消息队列进行异步处理之后，需要适当修改业务流程进行配合，比如用户在提交订单之后，订单数据写入消息队列，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功，以免交易纠纷。这就类似我们平时手机订火车票和电影票。

解耦

消息队列使利用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。

分布式事务的解决方案

可通过MQ来保证两个系统的最终一致性，即解决分布式事务问题。该MQ需要做到消息可靠发送和消息可靠消费。
用MQ解决分布式事务的方案通用性强、拓展性强、方案成熟，但只适合异步场景、存在延迟（需要业务上能够容忍）。

使用消息中间件带来的问题

1、系统可用性降低：系统可用性在某种程度上降低。引入MQ之后，需要考虑消息丢失或者说MQ挂掉等的情况。
2、系统复杂性提高：加入MQ之后，你需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题！
3、一致性问题：消息中间件可以实现异步，异步确实可以提高系统响应速度。但是，万一消息的真正消费者并没有正确消费消息怎么办？这样就会导致数据不一致的情况了!

常见的消息中间件对比

对比方向	概要
吞吐量	万级的ActiveMQ和RabbitMQ的吞吐量要比十万级甚至是百万级的RocketMQ和Kafka低一个数量级。
可用性	都可以实现高可用。ActiveMQ和RabbitMQ都是基于主从架构实现高可用性。RocketMQ基于分布式架构。kafka也是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用。
时效性	RabbitMQ基于erlang开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。其他三个都是 ms 级。
功能支持	除了Kafka，其他三个功能都较为完备。Kafka功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准。
消息丢失	ActiveMQ和RabbitMQ丢失的可能性非常低，RocketMQ和Kafka理论上不会丢失。