第一章 消息中间件简介

一、什么是消息中间件？

1、消息中间件(MQ)的定义

其实并没有标准定义。一般认为，消息中间件属于分布式系统中一个子系统，关注于数据的发送和接收，利用高效可靠的异步消息传递机制对分布式系统中的其余各个子系统进行集成。

高效：对于消息的处理处理速度快。

可靠：一般消息中间件都会有消息持久化机制和其他的机制确保消息不丢失。

异步：指发送完一个请求，不需要等待返回，随时可以再发送下一个请求，既不需要等待。

一句话总结，我们消息中间件不生产消息，只是消息的搬运工。

 

2、为什么要用消息中间件？

假设一个电商交易的场景，用户下单之后调用库存系统减库存，然后需要调用物流系统进行发货，如果交易、库存、物流是属于一个系统的，那么就是接口调用。但是随着系统的发展，各个模块越来越庞大、业务逻辑越来越复杂，必然是要做服务化和业务拆分的。这个时候就需要考虑这些系统之间如何交互，一般的处理方式就是 RPC（Remote Procedure Call）（具体实现 dubbo,SpringCloud）。

系统继续发展，可能一笔交易后续需要调用几十个接口来执行业务，比如还有风控系统、短信服务等等。这个时候就需要消息中间件登场来解决问题了。 所以消息中间件主要解决分布式系统之间消息的传递，同时为分布式系统中其他子系统提供了松耦合的架构，同时还有以下好处：

低耦合：

低耦合，不管是程序还是模块之间，使用消息中间件进行间接通信。

异步通信能力：

异步通信能力，使得子系统之间得以充分执行自己的逻辑而无需等待。

缓冲能力：

缓冲能力，消息中间件像是一个巨大的蓄水池，将高峰期大量的请求存储下来慢慢交给后台进行处理，对于秒杀业务来说尤为重要。

伸缩性：

伸缩性，是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。衡量架构是否高伸缩性的主要标准就是是否可用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。

扩展性：

扩展性，主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。比如用户购买电影票的应用，现在我们要增加一个功能，用户买了铁血战士的票后，随机抽取用户送异形的限量周边。怎么做到不改动用户购票功能的基础上增加这个功能。熟悉设计模式的同学，应该很眼熟，这是设计模式中的开闭原则（对扩展开放，对修改关闭）在架构层面的一个原则。

和RPC有何区别？

RPC 和消息中间件的场景的差异很大程度上在于就是“依赖性”和“同步性”。

依赖性：

 

比如短信通知服务并不是事交易环节必须的，并不影响下单流程，不是强依赖，所以交易系统不应该依赖短信服务。如果是 RPC 调用，短信通知服务挂了，整个业务就挂了，这个就是依赖性导致的，而消息中间件则没有这个依赖性。

消息中间件出现以后对于交易场景可能是调用库存中心等强依赖系统执行业务，之后发布一条消息（这条消息存储于消息中间件中）。像是短信通知服务、数据统计服务等等都是依赖于消息中间件去消费这条消息来完成自己的业务逻辑。

同步性： 

RPC 方式是典型的同步方式，让远程调用像本地调用。消息中间件方式属于异步方式。