消息队列、消息代理、消息中间件的区别和联系联系方式呢？希望这篇文章能告诉你答案。中间件（Middleware）首先，什么是中间件？我的理解是：中间件是帮助应用程序与其他应用程序、网络、硬件和操作系统进行交互或通信的软件。换句话说，更简洁：“将特定业务与底层逻辑分离的软件。”其实中间件软件的范围很广。日常使用的Redis、Nginx、Zookeeper、Memcached等都是“中间件”。所谓“中”，是相对于架构体系而言的。它不涉及具体的业务逻辑或底层硬件逻辑。用于用户数据交换和管理，可以起到“中介”的作用。这是中间件。那么问题来了：为什么需要中间件（代理）的帮助，直接和相应的应用程序、硬件、操作系统等进行交互/通信不是很好吗？在回答问题之前，我们必须明确：任何中间件一定是为了解决特定领域的某个（某些）问题而产生的。让我举两个例子来帮助你理解。1、数据库中间件当项目很小的时候，直接使用编程语言下的数据库驱动来操作数据库就够了。有些开发者会使用ORM方式来操作数据库：这就够了。但是随着业务的发展，数据量和读写的QPS越来越高，主从模式的MySQL实例压力越来越大。单纯升级服务器硬件已经不能满足生产环境的需要。我们公司不成文的习惯是单表不超过5000万条记录。当数据库量很大时，我们设计分库分表，即“分而治之”，将QPS和数据量分片限制在一个范围内。当然还有很多其他的相关功能，比如读写分离、路由策略、统计、管理、认证等等。这些都在业务逻辑之上，不应该堆在业务代码中。它们应该被抽象为一个独立的组件，即数据库中间件。现在主流的开源数据库中间件有Mycat、MySQL-proxy、Atlas等，但是现在都维护的不多了。另外还有Cetus，作者是tcpcopy的作者，这个项目还在维护中。如果你有兴趣，你可以试试。当然，其实各大公司都有自己的数据库中间件产品，更贴近公司的业务产品和基础设施。2.Web框架中间件Web框架一般都支持中间件。Web框架中间件的本质是一个插件系统，是一系列的框架钩子，在接收请求和返回响应的过程中做一些额外的事情。中间件的种类很多，举几个例子：响应压缩、日志支持、会话CSRF保护、验证/认证、访问控制、资源使用检查（比如内存使用）、请求索引健康检查、静态资源管理……这些中间件将执行业务和非业务代码功能解耦：框架中可能内置了一些常用的中间件，也可能只有内置的中间件支持。你可以配置和使用某些（某些）中间件，你也可以很方便地在web视图中自定义中间件。您不需要在Web视图中编写中间件逻辑。按照约定的用法，框架会在相应的生命周期中按照约定的顺序执行这些中间件。逻辑PS：Gin是Golang语言中最知名的web框架，支持中间件，也在官网推出了一个名为gin-gonic/contrib的项目，用于收集社区中间件。消息队列（MessageQueue）消息队列就是Message+Queue。实际上，一条消息可以说是一个数据传输单元，它包括创建时间、频道/主题信息、输入参数等所有数据；队列（Queue）是一种FIFO（先进先出）数据结构，编程语言一般都有内置（In-memory）队列实现，可以作为进程间通信（IPC）的一种方法。使用队列最常见的场景是生产者/消费者模式：生产者生产消息放入队列，消费者从队列中获取消息进行消费。准确的说，消息队列（以下简称MQ**）是一种可以实现从生产者到消费者的单向通信的通信模型，通俗的说，MQ就是指实现这种模型的中间件，比如RabbitMQ、RocketMQ、Kafka等想象一个下单场景，支付成功后做什么：通知/提醒系统。通知商家有人购买了Ta的商品，同时通知买家您购买成功（相当于确认订单）。通知/提醒的方式有很多种，会员系统如邮件、短信、应用内消息等。更新用户积分、等级等日志系统。订单这样重要的服务，需要日志，可以用于未来的追溯问题推荐系统。更新用户画像，再次向用户推荐他。Goodsofinterest..以下是一些问题：响应耗时。其实远不止于此，每一项都需要开销，增加了响应时间。如果这些逻辑同步执行，用户要等多久？这种体验是完全不能接受的！所以需要一个异步消费的机制来过耦合。本来只是一个订单系统，但是上面的东西要堆起来，就成了一个没有霸道应用的巨无霸，以后的开发维护会因为问题和错误而丢失。如果这些后续行为中的某个（某些）服务恰好失败，执行失败或者验证超时，但是必须完成支付成功的确认，那么就需要有一个地方来存放这些没有被正确处理的部分消费。）播送。就像上面的订单场景一样，支付成功的消息被发送到多个子系统，相当于多播。以后如果要增加或删除feeds，如何方便的实现呢？当然还有其他的问题：秒杀场景下的并发量可能很高，很有可能会出现远远超过现有服务器处理能力的情况。很容易使系统崩溃。如果出现这样的问题，将未处理的消息放入消息队列，就可以实现“削峰”和“限流”的功能。在某些场景下，有消息优先级的需求……而消息中间件解决了上述问题。虽然不同的中间件实现方式不同，但都具有以下特点：分布式。消息中间件实际上解决了分布式系统之间的消息传递问题。消费者可以分布在多个服务器上。一方面降低了单点故障导致消息队列阻塞的风险。另一方面，横向扩展也很容易。耐用可靠。消息队列一般会将接收到的消息存储在本地硬盘上，以保证消息发送前不会莫名其妙的丢失。高性能和高吞吐量。比如RocketMQ具备亿级消息积累能力，广泛应用于阿里系统各种高并发场景；而Kafka在实时计算、日志采集等场景中是行业标准。可以说消息中间件是现在企业架构中不可或缺的一部分，用起来还是不错的。消息代理（MessageBroker）MessageBroker是一种用于消息验证、转换和路由的架构模式。虽然不同的消息中间件架构和实现方式不同，但大多实现了Broker：其实就是一个消息中间件服务器，是中间件的核心。注意：RabbitMQ、Kafka、RocketMQ等都有消息代理，但注意并不是所有的中间件都选择这种方式，比如ZeroMQ，它使用的是套接字风格的API。在某些地方，消息代理实际上指的是消息中间件，例如Python语言中著名的分布式任务队列框架Celery（所谓的“任务”，其实就是包含了任务所有数据的消息）。
