如何使用RabbitMQ实现RPC-创新互联

这篇文章给大家分享的是有关如何使用RabbitMQ实现RPC的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。

创新互联公司是一家集网站建设,周口企业网站建设,周口品牌网站建设,网站定制,周口网站建设报价,网络营销,网络优化,周口网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

背景知识

RabbitMQ

RabbitMQ 是基于 AMQP 协议实现的一个消息队列（Message Queue），Message Queue 是一个典型的生产者/消费者模式。生产者发布消息，消费者消费消息，生产者和消费者之间是解耦的，互相不知道对方的存在。

RPC

Remote Procedure Call：远程过程调用，一次远程过程调用的流程即客户端发送一个请求到服务端，服务端根据请求信息进行处理后返回响应信息，客户端收到响应信息后结束。

如何使用 RabbitMQ 实现 RPC？

使用 RabbitMQ 实现 RPC，相应的角色是由生产者来作为客户端，消费者作为服务端。

但 RPC 调用一般是同步的，客户端和服务器也是紧密耦合的。即客户端通过 IP/域名和端口链接到服务器，向服务器发送请求后等待服务器返回响应信息。

但 MQ 的生产者和消费者是完全解耦的，那么如何用 MQ 实现 RPC 呢？很明显就是把 MQ 当作中间件实现一次双向的消息传递：

客户端和服务端即是生产者也是消费者。客户端发布请求，消费响应；服务端消费请求，发布响应。

具体实现

MQ部分的定义

请求信息的队列

我们需要一个队列来存放请求信息，客户端向这个队列发布请求信息，服务端消费该队列处理请求。该队列不需要复杂的路由规则，直接使用 RabbitMQ 默认的 direct exchange 来路由消息即可。

响应信息的队列

存放响应信息的队列不应只有一个。如果存在多个客户端，不能保证响应信息被发布请求的那个客户端消费到。所以应为每一个客户端创建一个响应队列，这个队列应该由客户端来创建且只能由这个客户端使用并在使用完毕后删除，这里可以使用 RabbitMQ 提供的排他队列（Exclusive Queue）：

channel.queueDeclare(queue:"", durable:false, exclusive:true, autoDelete:false, new HashMap<>())

并且要保证队列名唯一，声明队列时名称设为空 RabbitMQ 会生成一个唯一的队列名。

exclusive 设为 true 表示声明一个排他队列，排他队列的特点是只能被当前的连接使用，并且在连接关闭后被删除。

一个简单的 demo（使用 pull 机制）

我们使用一个简单的 demo 来了解客户端和服务端的处理流程。

发布请求

• 编写代码前的一个小问题

我们在声明队列时为每一个客户端声明了独有的响应队列，那服务器在发布响应时如何知道发布到哪个队列呢？其实就是客户端需要告诉服务端将响应发布到哪个队列，RabbitMQ 提供了这个支持，消息体的 Properties 中有一个属性 reply_to 就是用来标记回调队列的名称，服务器需要将响应发布到 reply_to 指定的回调队列中。

解决了这个问题之后我们就可以编写客户端发布请求的代码了：

// 定义响应回调队列
String replyQueueName = channel.queueDeclare("", false, true, false, new HashMap<>()).getQueue();
// 设置回调队列到 Properties
AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
 .replyTo(replyQueueName)
 .build();
String request = "request";
// 发布请求
channel.basicPublish("", "rpc_queue", properties, request.getBytes());

Direct reply-to：

RabbitMQ 提供了一种更便捷的机制来实现 RPC，不需要客户端每次都定义回调队列，客户端发布请求时将 replyTo 设为 amq.rabbitmq.reply-to ，消费响应时也指定消费 amq.rabbitmq.reply-to ，RabbitMQ 会为客户端创建一个内部队列

消费请求

接下来是服务端处理请求的部分，接收到请求后经过处理将响应信息发布到 reply_to 指定的回调队列：

// 服务端 Consumer 的定义
public class RpcServer extends DefaultConsumer {
 public RpcServer(Channel channel) {
 super(channel);
 }
 @Override
 public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
 String msg = new String(body);
 String response = (msg + " Received");
 // 获取回调队列名
 String replyTo = properties.getReplyTo();
 // 发布响应消息到回调队列
 this.getChannel().basicPublish("", replyTo, new AMQP.BasicProperties(), response.getBytes());
 }
}
...
// 启动服务端 Consumer
channel.basicConsume("rpc_queue", true, new RpcServer(channel));

接收响应

客户端如何接收服务器的响应呢？有两种方式：1.轮询的去 pull 回调队列中的消息，2.异步的消费回调队列中的消息。我们在这里简单实现第一种方案。

GetResponse getResponse = null;
while (getResponse == null) {
 getResponse = channel.basicGet(replyQueueName, true);
}
String response = new String(getResponse.getBody());

一个简单的基于 RabbitMQ 的 RPC 模型已经实现了，但这个 demo 并不实用，因为客户端每次发送完请求都要同步的轮询等待响应消息，只能每次处理一个请求。RabbitMQ 的 pull 模式效率也比较低。

实现一个完备可用的 RPC 模式需要做的工作还有很多，要处理的关键点也比较复杂，有句话叫不要重复造轮子，spring 已经实现了一个完备可用的 RPC 模式的库，接下来我们来了解一下。顺便在此给大家推荐一个Java架构方面的交流学习群：698581634，进群即可获取Java架构师资料：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系，群里一定有你需要的资料，大家赶紧加群吧。

Spring Rabbit 中的实现

和上面 demo 的 pull 模式一次只能处理一个请求相对应的：如何异步的接收响应并处理多个请求呢？关键点就在于我们需要记录请求和响应并将它们关联起来，RabbitMQ 也提供了支持，Properties 中的另一个属性 correlation_id 用来标识一个消息的唯一 id。

参考 spring-rabbit 中的 convertSendAndReceive 方法的实现，为每一次请求生成一个唯一的 correlation_id ：

private final AtomicInteger messageTagProvider = new AtomicInteger();
...
String messageTag = String.valueOf(this.messageTagProvider.incrementAndGet());
...
message.getMessageProperties().setCorrelationId(messageTag);

并使用一个 ConcurrentHashMap 来维护 correlation_id 和响应信息的映射：

private final Map replyHolder = new ConcurrentHashMap();
...
final PendingReply pendingReply = new PendingReply();
this.replyHolder.put(correlationId, pendingReply);

PendingReply 中有一个 BlockingQueue 存放响应信息，在发送完请求信息后调用 BlockingQueue 的 pull 方法并设置超时时间来获取响应：

private final BlockingQueue