分布式消息队列中间件详解

https://faxian.lagou.com/discover/e0d037220b964ccd93a079e3bc4445b0.html?ver=1562142471380&token=9202f7e89f7fc628a6d19bd82143a7bb7d348513c8566ab1e321224f75b03b14&checkCode=69f64f39-986d-4f22-ba48-c51cf5b13a31&verify=d4a265b32c7897f257ed4e66892da52a&lagoufrom=noapp&from=singlemessage&isappinstalled=0

 

步架构的两种主要模型

使用消息队列构建异步的调用架构，你还需要知道两种模型：点对点模型和发布订阅模型。

1.点对点模型

CgotOV0cZCCAaRu-AADyYw3q170674.png

消费者和生产者只需要知道消息队列的名字，生产者发送消息到消息队列中，而消息队列的另一端是多个消费者竞争消费消息，每个到达消息队列的消息只会被路由到一个消费者中去，所以消费者看到的是全部消息的一个子集。我们看这张图，消息的生产者有多个，消息的消费者也有多个，多个生产者将消息发送到消息队列中，而有多个消费者去消息队列中对消息进行竞争性的消费。每个消息只会被一个消费者消费，每个消费者只会消费消息队列中的一部分消息。

2.发布订阅模型

CgoB5l0cZCCATCikAADxUG0xvMQ331.png

在发布订阅模型中，消息可能被发送到不止一个消费者，生产者发送消息到一个主题，而不是队列中。消息被发布到主题后，就会被克隆给每一个订阅它的消费者，每个消费者接收一份消息复制到自己的私有队列。消费者可以独立于其他消费者使用自己订阅的消息，消费者之间不会竞争消息。常用的分布式消息队列都支持发布订阅模型，也就是说消息的发布订阅模型是分布式消息队列的一个功能特性。

3.两个模型的应用

点对点模型：主要用于一些耗时较长的、逻辑相对独立的业务。

比如说我前面的讲到的发送邮件这样一个操作。因为发送邮件比较耗时，而且应用程序其实也并不太关心邮件发送是否成功，发送邮件的逻辑也相对比较独立，所以它只需要把邮件消息丢到消息队列中就可以返回了，而消费者也不需要关心是哪个生产者去发送的邮件，它只需要把邮件消息内容取出来以后进行消费，通过远程服务器将邮件发送出去就可以了。而且每个邮件只需要被发送一次。所以消息只被一个消费者消费就可以了。

发布订阅模型：如新用户注册这样一个消息，需要使用按主题发布的方式。

比如新用户注册，一个新用户注册成功以后，需要给用户发送一封激活邮件，发送一条欢迎短信，还需要将用户注册数据写入数据库，甚至需要将新用户信息发送给关联企业的系统，比如淘宝新用户信息发送给支付宝，这样允许用户可以一次注册就能登录使用多个关联产品。一个新用户注册，会把注册消息发送给一个主题，多种消费者可以订阅这个主题。比如发送邮件的消费者、发送短信的消费者、将注册信息写入数据库的消费者，跨系统同步消息的消费者等。

消息队列的好处

1.实现异步处理，提升处理性能

对一些比较耗时的操作，可以把处理过程通过消息队列进行异步处理。这样做可以推迟耗时操作的处理，使耗时操作异步化，而不必阻塞客户端的程序，客户端的程序在得到处理结果之前就可以继续执行，从而提高客户端程序的处理性能。

2.可以让系统获得更好的伸缩性

耗时的任务可以通过分布式消息队列，向多台消费者服务器并行发送消息，然后在很多台消费者服务器上并行处理消息，也就是说可以在多台物理服务器上运行消费者。那么当负载上升的时候，可以很容易地添加更多的机器成为消费者。

CgoB5l0cZW2AQtl4AAChKMZj6ek478.png

如图中的例子，用户上传文件后，通过发布消息的方式，通知后端的消费者获取数据、读取文件，进行异步的文件处理操作。那么当前端发布更多文件的时候，或者处理逻辑比较复杂的时候，就可以通过添加后端的消费者服务器，提供更强大的处理能力。

3.可以平衡流量峰值，削峰填谷

使用消息队列，即便是访问流量持续的增长，系统依然可以持续地接收请求。这种情况下，虽然生产者发布消息的速度比消费者消费消息的速度快，但是可以持续的将消息纳入到消息队列中，用消息队列作为消息的缓冲，因此短时间内，发布者不会受到消费处理能力的影响。

CgotOV0cZW2AeZy2AACNJtVMQ6U394.png

从这张图可以看到，因为消息的生产者是直接面向用户请求的，而用户的请求访问压力是不均衡的。如淘宝每天的访问高峰是在上午10点左右，而新浪微博则可能在某个明星半夜发一条微博后突然出现访问高峰。

在访问高峰，用户的并发访问数可能超过了系统的处理能力，所以在高峰期就可能会导致系统负载过大，响应速度变慢，更严重的可能会导致系统崩溃。这种情况下，通过消息队列将用户请求的消息纳入到消息队列中，通过消息队列缓冲消费者处理消息的速度。

如图中所示，消息的生产者它有高峰有低谷，但是到了消费者这里，只会按照自己的最佳处理能力去消费消息。高峰期它会把消息缓冲在消息队列中，而在低谷期它也还是使用自己最大的处理能力去获取消息，将前面缓冲起来、来不及及时处理的消息处理掉。那么，通过这种手段可以实现系统负载消峰填谷，也就是说将访问的高峰消掉，而将访问的低谷填平，使系统处在一个最佳的处理状态之下，不会对系统的负载产生太大的冲击。

4.失败隔离和自我修复

因为发布者不直接依赖消费者，所以分布式消息队列可以将消费者系统产生的错误异常与生产者系统隔离开来，生产者不受消费者失败的影响。 当在消息消费过程中出现处理逻辑失败的时候，这个错误只会影响到消费者自身，而不会传递给消息的生产者，也就是应用程序可以按照原来的处理逻辑继续执行。

所以，这也就意味着在任何时候都可以对后端的服务器执行维护和发布操作。可以重启、添加或删除服务器，而不影响生产者的可用性，这样简化了部署和服务器管理的难度。

5.可以使生产者和消费者的代码实现解耦合

也就是说可以多个生产者发布消息，多个消费者处理消息，共同完成完整的业务处理逻辑，但是它们的不需要直接的交互调用，没有代码的依赖耦合。在传统的同步调用中，调用者代码必须要依赖被调用者的代码，也就是生产者代码必须要依赖消费者的处理逻辑代码，代码需要直接的耦合，而使用消息队列，这两部分的代码不需要进行任何的耦合。

耦合程度越低的代码越容易维护，也越容易进行扩展。

CgoB5l0cZW2ATSZ9AACIDXrxUng248.png

比如新用户注册，如果用传统同步调用的方式，那么发邮件、发短信、写数据库、通知关联系统这些代码会和用户注册代码直接耦合起来，整个代码看起来就是完成用户注册逻辑后，后面必然跟着发邮件、发短信这些代码。如果要新增一个功能，比如将监控用户注册情况，将注册信息发送到业务监控系统，就必须要修改前面的代码，至少增加一行代码，发送注册信息到监控系统，我们知道，任何代码的修改都可能会引起bug。

而使用分布式消息队列实现生产者和消费者解耦合以后，用户注册以后，不需要调用任何后续处理代码，只需要将注册消息发送到分布式消息队列就可以了。如果要增加新功能，只需要写个新功能的消费者程序，在分布式消息队列中，订阅用户注册主题就可以了，不需要修改原来任何一行代码。

这种解耦的特点对于团队的工作分工也很有帮助！从消息生产者的视角看，它只需要构建消息，将消息放入消息队列中，开发就完成了。而从消费者的开发视角看，它只需要从消息队列中获取消息，然后进行逻辑处理。它们彼此之间不进行任何耦合。消息的生产者不关心放入消息队列中下一步会发生什么，而消费者也不需要知道消息从哪里来。这两部分程序的开发者也可以不关心彼此的工作进展，他们开发的代码也不需要集成在一起，只要约定好消息格式，就可以各自开发了。

常用的消息队列产品

目前业界常用的消息队列产品，有这么几种：RabbitMQ 、ActiveMQ、RocketMQ 、Kafka。

1. RabbitMQ 的主要特点是性能好，社区活跃，但是RabbitMQ用Erlang开发，我们的应用很少用Erlang，所以不便于二次开发和维护。
2. ActiveMQ 影响比较广泛，可以跨平台，使用Java开发，对Java比较友好。
3. RocketMQ 是阿里推出的一个开源产品，也是使用Java开发，性能比较好，可靠性也比较高。
4. Kafka 是LinkedIn出品的，专门针对分布式场景进行了优化，因此分布式的伸缩性会比较好。

目前看来，Kafka因为最初设计时就是针对互联网的分布式、高可用应用场景而设计，并且在大数据领域得到广泛支持，资料文档更加完善，因此在互联网企业得到更多的应用。

这里跟大家分享一个进行技术产品选型的小技巧，供你在进行技术决策的时候参考。当在几个相似的技术产品中进行选型决策，如果拿不定主意，感觉都差不多的时候，一个办法就是利用搜索引擎搜索一下这些产品的名字，搜索结果最多的产品，代表了这个产品是最热门，文档资料最多的、遇到问题有更大概率可以通过搜索引擎找到答案的，最有发展前景、不会半途而废没人维护的。

利用这个技巧，我们看一下消息队列MQ的产品选型，Kafka在百度中的搜索结果数量是其他三个MQ产品的搜索结果数量之和，那么如果你拿不定主意，选择Kafka至少不会是一个糟糕的选择。

以上内容摘取自拉勾

《阿里前辈的架构经》  第03讲（分布式消息队列）主讲人：李智慧，前阿里巴巴技术专家