对于分布式消息中间件，首先要了解两个基础的概念，即什么是分布式系统，什么又是中间件。
分布式系统
“A distributed system is one in which components located at networked computers communicate and coordinate their actions only by passing messasges.”——《Distributed Systems Concepts and Design》
从上面这个解释可以得到分布式系统的两个特点：
组件分布在网络计算机上
组件之间通过消息来协调行动
中间件
Middleware is computer software that provides services to software applications beyond those available from the operating system. It can be described as "software glue". Middleware makes it easier for software developers to implement communication and input/output, so they can focus on the specific purpose of their application.——维基百科
中间件被描述为为应用程序提供操作系统所提供的服务之外的服务，简化应用程序的通信、输入输出的开发，使他们专注于自己的业务逻辑。
从维基百科上对中间件的解释感觉有点绕，其实可以从“空间”的角度去理解中间件，即中间件是处于“中间层”的组件，是上层的应用程序和底层的服务之间的桥梁（比如DB中间件的上层是应用程序，底层是DB服务），也是应用与应用之间的桥梁（比如分布式服务组件）。
分布式消息中间件
“Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems.”——维基百科
维基百科给出的消息中间件的定义是支持在分布式系统中发送和接受消息的硬件或软件基础设施（对我们这里讨论的范围来说肯定就是软件了）。
那么分布式消息中间件其实就是指消息中间件本身也是一个分布式系统。
消息中间件能做什么？
任何中间件必然都是要去解决特定领域的某个问题，消息中间件解决的就是分布式系统之间消息传递的问题。消息传递是分布式系统必然要面对的一个问题。
假设一个电商交易的场景，用户下单之后调用库存系统减库存，然后需要调用物流系统进行发货，如果交易、库存、物流是属于一个系统的，那么就是接口调用。但是随着系统的发展，各个模块越来越庞大、业务逻辑越来越复杂，必然是要做服务化和业务拆分的。这个时候就需要考虑这些系统之间如何交互，第一反应就是RPC（Remote Procedure Call）。系统继续发展，可能一笔交易后续需要调用几十个接口来执行业务，比如还有风控系统、短信服务等等。这个时候就需要消息中间件登场来解决问题了。
笔者认为，RPC和消息中间件的场景的差异很大程度上在于就是“依赖”和“量”。比如短信通知服务并不是事交易环节必须的，并不影响下单流程，不是强依赖，所以交易系统不应该依赖短信服务。比如一些数据分析程序可能需要在拿到一天的总销售量，这个就只需要销售中心提供接口在需要时调用即可。
消息中间件出现以后对于交易场景可能是调用库存中心等强依赖系统执行业务，之后发布一条消息（这条消息存储于消息中间件中）。像是短信通知服务、数据统计服务等等都是依赖于消息中间件去消费这条消息来完成自己的业务逻辑。
从以上的场景可以看出消息中间件其实就是对系统进行了解耦，同时带来了异步化等好处。
简单概括一下消息中间件的应用场景大致如下：
业务解耦：交易系统不需要知道短信通知服务的存在，只需要发布消息
削峰填谷：比如上游系统的吞吐能力高于下游系统，在流量洪峰时可能会冲垮下游系统，消息中间件可以在峰值时堆积消息，而在峰值过去后下游系统慢慢消费消息解决流量洪峰的问题
事件驱动：系统与系统之间可以通过消息传递的形式驱动业务，以流式的模型处理
分布式消息中间件长什么样？
一个抽象的对分布式消息中间件的认知大概是这样：
有一个SDK，提供给业务系统发送、消费消息的接口
有一批Server节点用于接受和存储消息，并在合适的时候发送给下游的系统进行消费
