RabbitMQ实战：消息通讯模式和最佳实践

本系列是「RabbitMQ实战：高效部署分布式消息队列」书籍的总结笔记。

经过前2篇的介绍，了解了消息通讯的主要元素和交互过程，以及如何运行和管理RabbitMQ，这篇将站在开发模式的角度理解「面向消息通讯」带来的好处，以及在各类场景下的最佳实践。

经过介绍，你会了解到：

• 面向消息通讯的好处
• 发后即忘模型
• 用RabbitMQ实现RPC

面向消息通讯的好处

主要从异步状态思惟、处理能力扩展性、集成复杂度方面，说明面向消息通讯的好处。

异步状态思惟

当将消息通讯集成到应用程序时，开发模式将从同步模型变为异步模型，RabbitMQ提供了不一样的方法，容许咱们在一处发送请求，在另外一处进行处理，这样同步程序能够继续执行其余逻辑。

举个简单的例子来讲明，经过支付宝还信用卡：

• 用户填写信用卡号、发卡银行、持卡人姓名、还款金额，提交还款申请；
• 支付宝会当即提示用户，申请已提交，多少小时内完成还款；
• 还款完成后，会推送给用户一条消息，提醒还款是否成功；

若是是同步请求，用户须要等待几个小时查看结果，等待过程当中不能进行其余操做，这是很不合理的。

异步的思惟是将请求和处理分离，在应用中紧密耦合的两部分中间使用RabbitMQ，请求解析后，发送一条业务可以理解的消息到RabbitMQ，就返回给用户，真正的处理由另外的服务异步处理。

扩展性

随着业务的扩展，对服务处理能力的要求愈来愈高，RabbitMQ能够很简单的增长处理能力。

由于RabbitMQ能够将请求在处理服务器间平均地分发，不须要负载均衡器了。

零成本API

系统间相互调用，须要约定一套API，一般来说，须要花费一点点时间，编写一大段代码将传入的HTTP请求转化为应用程序中的函数调用。

若是使用AMQP来链接应用程序的各个部分，无需额外定义API，使用消息通讯便可。另外， AMQP是语言无关的，拥有数十种语言的本地语言绑定。

发后即忘模型

当考虑消息通讯可以解决的问题类型时，消息通讯适用的主要领域是的「发后即忘」处理模式。关心的是任务将会完成，但无须实时完成，建立一个任务，发送到交换器上后，就能够返回继续工做，甚至都不须要通知用户任务已经完成。

匹配该模式的两种类型任务：

• 批处理：针对大型数据集合的工做或者转换，多个任务对数据集合的独立部分进行操做；
• 通知：对发送事件的描述，能够是消息的日志，或者通知另外一个程序或者管理员；

书上介绍的实例比较简单，就不在此列出了，主要是根据不一样的场景，肯定交换器的类型和routingkey，能够参考上一篇介绍的「收集日志」的例子进行理解。

用RabbitMQ实现RPC

有多种方式来实现远程过程调用RPC，好比REST API、SOAP、Thrift等，这些传统的RPC实现方法有共同之处：客户端和服务器紧密相连、并且要等待返回结果。另外考虑这些问题：

• 当有多个服务节点时，客户端如何发现对应服务器；
• 若是客户端链接的RPC服务器崩溃了，客户端须要额外逻辑进行重连；

经过MQ服务器来实现时，只是简单地发布消息而已，将消息路由到合适的地方放，经过多台RPC服务器对消息进行负载均衡，当处理消息的服务器崩溃时，将RPC消息重发到另外一台。

如今的问题在于，若是将应答返回给客户端？

RabbitMQ使用消息来发回应答，在AMQP消息头里有一个字段叫作reply_to，消息的生成者能够经过该字段来肯定队列名称，并监听队列等待应答，消息接收者可以检查reply_to字段，并建立包含应答内容的新的消息，并以队列名称做为路由键。

关于reply_to的队列名称，若是生成者声明了没有名字的队列，RabbitMQ为自动生成一个惟一的队列名，同时在声明的时候指定exclusive参数，确保只有建立队列的生产者能够读取队列上的消息。

这样，全部RPC客户端要作的，就是声明临时的、排他的、匿名队列，并将该队列名称包含到RPC消息的reply_to头中，这样服务器端就知道应答消息该发往哪儿了。

不少场景使用「发后即忘」模型，不须要处理者响应，若是须要响应，可使用RabbitMQ的RPC模型。

下一篇将介绍RabbitMQ集群和高可用性以及它们的设置。

欢迎扫描下方二维码，关注个人我的微信公众号 ~