官方 RabbitMQ 教程 - 6 RPC

最新推荐文章于 2024-10-06 20:46:09 发布

一线大码

最新推荐文章于 2024-10-06 20:46:09 发布

阅读量146

点赞数

分类专栏： RabbitMQ 文章标签： rabbitmq

本文链接：https://blog.csdn.net/wb1046329430/article/details/115290260

版权

RabbitMQ 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

文章目录

官方文档地址： 6 RPC

请求/应答模式的例子。

前提条件

本教程假设你已经安装了 RabbitMQ 并在本地主机端口（5672）上运行。

远程过程调用（RPC）

RPC：Remote Procedure Call。

在第二篇教程中，我们学习了如何使用工作队列在多个worker之间分配耗时的任务。

但是，如果我们需要在远程计算机上运行一个函数并等待结果呢？嗯，那是另一回事了。这种模式通常称为远程过程调用或 RPC 。

在本教程中，我们将使用 RabbitMQ 构建一个 RPC 系统：一个客户端和一个可扩展的 RPC 服务器。因为我们没有任何值得分发的耗时任务，所以我们将创建一个返回斐波那契数列（一种整数数列）的虚拟 RPC 服务。

客户端接口

为了说明如何使用 RPC 服务，我们将创建一个简单的客户端类。它将公开一个名为call的方法，发送一个 RPC 请求并阻塞，直到收到应答：

FibonacciRpcClient fibonacciRpc = new FibonacciRpcClient();
String result = fibonacciRpc.call("4");
System.out.println( "fib(4) is " + result);

关于RPC的说明

尽管 RPC 是计算中非常常见的模式，但它经常受到批评。当程序员不知道函数调用是本地的还是缓慢的 RPC 时，就会出现问题。这样的混淆会导致不可预测的系统，并给调试增加不必要的复杂性。滥用 RPC 会导致不可维护的意大利面条式代码，而不是简化代码。

记住这一点，考虑以下建议：

可明显区分哪个函数调用是本地的，哪个是远程的。
系统文档。明确组件之间的依赖关系。
处理错误情况。当 RPC 服务器挂掉很长时间时，客户端应该如何反应？

当有疑问时，避免使用 RPC。如果可以，您应该使用异步传输 - 而不是类似 RPC 的阻塞，结果被异步地推到下一个计算阶段。

回调队列

通常，在 RabbitMQ 上执行 RPC 是很容易的。客户端发送请求消息，服务器使用响应消息进行应答。为了接收响应，我们需要发送的请求中携带一个'callback'队列地址。我们可以使用默认队列（它在 Java 客户端中是独占的，第三篇教程的临时队列中有讲）。让我们试一试：

callbackQueueName = channel.queueDeclare().getQueue();

BasicProperties props = new BasicProperties
                            .Builder()
                            .replyTo(callbackQueueName)
                            .build();

channel.basicPublish("", "rpc_queue", props, message.getBytes());

// ... 然后编写代码从callback_queue读取响应消息 ...

消息属性

AMQP 0-9-1协议预先定义了与消息一起使用的14个属性。大多数属性很少被使用，除了以下几点：

deliveryMode：将消息标记为持久的（值为2）或瞬时的（任何其他值）。您可能还记得第二篇教程中的这个属性。（使用MessageProperties的值进行设置，参见第二篇教程。）
contentType：用于描述编码的mime-type。例如，对于经常使用的JSON编码，最好将此属性设置为application/json。
replyTo：通常用于命名回调队列。
correlationId：用于将 RPC 响应与请求关联起来。

我们需要这个新的导入：

import com.rabbitmq.client.AMQP.BasicProperties;

关联 ID

在上述方法中，我们提出为每个 RPC 请求创建一个回调队列。这非常低效，但幸运的是，有一种更好的方法 - 我们可以为每个客户端创建一个回调队列。

这就产生了一个新问题，在接收到队列中的响应后，不清楚响应属于哪个请求。这时就用上了correlationId属性。我们将为每个请求设置一个惟一的值。稍后，当我们在回调队列中接收到消息时，我们将查看此属性，根据这个属性，我们就能够将响应与请求匹配起来。如果我们看到一个未知的correlationId值，我们可以放心地丢弃消息 - 它不属于我们的请求。

您可能会问，为什么我们应该忽略回调队列中的未知消息，而不是由于错误导致失败？这是由于服务器端可能存在竞争条件。虽然不太可能，但 RPC 服务器有可能在向我们发送应答之后，在发送请求的确认消息之前死亡。如果发生这种情况，重新启动的 RPC 服务器将再次处理请求。这就是为什么在客户端上我们必须优雅地处理重复的响应，而 RPC 在理想情况下应该是幂等的。

综述

我们的 RPC 将这样工作：

对于 RPC 请求，客户端发送一个带有两个属性的消息：将replyTo设置为仅为请求创建的匿名独占队列，将correlationId设置为每个请求的惟一值。
请求被发送到rpc_queue队列。
RPC 工作程序（即服务器）正在该队列上等待请求。当出现一个请求时，它执行任务并使用replyTo字段中的队列将结果发送回客户端。
客户端在应答队列上等待数据。当消息出现时，它检查correlationId属性。如果它匹配请求的值，则返回应用程序的响应。

把它们放一起

斐波那契的任务：

private static int fib(int n) {
    if (n == 0) return 0;
    if (n == 1) return 1;
    return fib(n-1) + fib(n-2);
}

我们声明了斐波那契函数。它假设只有有效的正整数输入。(不要期望这个方法适用于大的数字，它可能是最慢的递归实现)。

我们的 RPC 服务器的代码RPCServer.java如下所示：

import com.rabbitmq.client.*;

public class RPCServer {

    private static final String RPC_QUEUE_NAME = "rpc_queue";

    private static int fib(int n) {
        if (n == 0) return 0;
        if (n == 1) return 1;
        return fib(n - 1) + fib(n - 2);
    }

    public static void main(String[] argv) throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost("localhost");

        try (Connection connection = factory.newConnection();
             Channel channel = connection.createChannel()) {
            channel.queueDeclare(RPC_QUEUE_NAME, false, false, false, null);
            channel.queuePurge(RPC_QUEUE_NAME);

            channel.basicQos(1);

            System.out.println(" [x] Awaiting RPC requests");

            Object monitor = new Object();
            DeliverCallback deliverCallback = (consumerTag, delivery) -> {
                AMQP.BasicProperties replyProps = new AMQP.BasicProperties
                        .Builder()
                        .correlationId(delivery.getProperties().getCorrelationId())
                        .build();

                String response = "";

                try {
                    String message = new String(delivery.getBody(), "UTF-8");
                    int n = Integer.parseInt(message);

                    System.out.println(" [.] fib(" + message + ")");
                    response += fib(n);
                } catch (RuntimeException e) {
                    System.out.println(" [.] " + e.toString());
                } finally {
                    channel.basicPublish("", delivery.getProperties().getReplyTo(), replyProps, response.getBytes("UTF-8"));
                    channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
                    //RabbitMq消费者线程通知RPC服务器所有者线程
                    synchronized (monitor) {
                        monitor.notify();
                    }
                }
            };

            channel.basicConsume(RPC_QUEUE_NAME, false, deliverCallback, (consumerTag -> { }));
            //等待并准备使用来自RPC客户端的消息
            while (true) {
                synchronized (monitor) {
                    try {
                        monitor.wait();
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
        }
    }
}

服务器代码相当简单：

与往常一样，我们首先建立连接、通道和声明队列。
我们可能需要运行多个服务器进程。为了在多个服务器上平均分配负载，我们需要在channel.basicQos中设置prefetchCount。
我们使用basicConsume来访问队列，在队列中，我们以对象（DeliverCallback）的形式提供一个回调，它将完成工作并将响应发送回去。

我们的 RPC 客户端的代码RPCClient.java如下所示：

import com.rabbitmq.client.AMQP;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;

import java.io.IOException;
import java.util.UUID;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.TimeoutException;

public class RPCClient implements AutoCloseable {

    private Connection connection;
    private Channel channel;
    private String requestQueueName = "rpc_queue";

    public RPCClient() throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost("localhost");

        connection = factory.newConnection();
        channel = connection.createChannel();
    }

    public static void main(String[] argv) {
        try (RPCClient fibonacciRpc = new RPCClient()) {
            for (int i = 0; i < 32; i++) {
                String i_str = Integer.toString(i);
                System.out.println(" [x] Requesting fib(" + i_str + ")");
                String response = fibonacciRpc.call(i_str);
                System.out.println(" [.] Got '" + response + "'");
            }
        } catch (IOException | TimeoutException | InterruptedException e) {
            e.printStackTrace();
        }
    }

    public String call(String message) throws IOException, InterruptedException {
        final String corrId = UUID.randomUUID().toString();

        String replyQueueName = channel.queueDeclare().getQueue();
        AMQP.BasicProperties props = new AMQP.BasicProperties
                .Builder()
                .correlationId(corrId)
                .replyTo(replyQueueName)
                .build();

        channel.basicPublish("", requestQueueName, props, message.getBytes("UTF-8"));

        final BlockingQueue<String> response = new ArrayBlockingQueue<>(1);

        String ctag = channel.basicConsume(replyQueueName, true, (consumerTag, delivery) -> {
            if (delivery.getProperties().getCorrelationId().equals(corrId)) {
                response.offer(new String(delivery.getBody(), "UTF-8"));
            }
        }, consumerTag -> {
        });

        String result = response.take();
        channel.basicCancel(ctag);
        return result;
    }

    public void close() throws IOException {
        connection.close();
    }
}

客户端代码稍微复杂一些：

我们建立连接和channel。
我们的call方法发出实际的 RPC 请求。
在这里，我们首先生成一个惟一的correlationId并保存它——我们的消费者回调将使用这个值来匹配适当的响应。
然后，我们为应答创建一个专用的独占队列并订阅它。
接下来，我们使用两个属性发布请求消息：replyTo和correlationId。
此时，我们可以坐下来等待适当的响应到来。
因为我们的消费者交付处理是在一个单独的线程中进行的，所以我们需要在响应到达之前挂起main线程。使用BlockingQueue是一种可能的解决方案。这里我们创建的ArrayBlockingQueue的容量设置为1，因为我们只需要等待一个响应。
消费者正在做一个非常简单的工作，对于每个消费的响应消息，它检查correlationId是否是我们要查找的。如果是，它将响应放入BlockingQueue。
与此同时，main线程正在等待从BlockingQueue获取响应。
最后，我们将响应返回给用户。

客户端请求：

RPCClient fibonacciRpc = new RPCClient();

System.out.println(" [x] Requesting fib(30)");
String response = fibonacciRpc.call("30");
System.out.println(" [.] Got '" + response + "'");

fibonacciRpc.close();

像往常一样编译并设置类路径(参见教程1)：

javac -cp $CP RPCClient.java RPCServer.java

我们的RPC服务现在已经准备好了。我们可以启动服务器：

java -cp $CP RPCServer
# => [x] Awaiting RPC requests

运行客户端，请求一个斐波纳契数：

java -cp $CP RPCClient
# => [x] Requesting fib(30)

这里介绍的设计并不是 RPC 服务的唯一可能实现，但是它有一些重要的优点：

如果 RPC 服务器太慢，您可以通过运行另一个服务器来扩展。尝试在新的控制台中运行第二个RPCServer。
在客户端，RPC 只需要发送和接收一条消息。不需要像queueDeclare这样的同步调用。因此，RPC 客户端对于单个 RPC 请求只需要一次网络往返。

我们的代码仍然非常简单，并没有试图解决更复杂（但重要）的问题，如：

如果没有服务器在运行，客户端应该如何反应？
客户端应该为 RPC 设置某种超时吗？
如果服务器发生故障并引发异常，是否应该将其转发给客户端？
在处理之前防止无效的传入消息（如检查界限、类型）。

如果您想试验一下，可能会发现管理界面对于查看队列非常有用。

一线大码

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录