官方文档地址: 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 的阻塞,结果被异步地推到下一个计算阶段。
扫描二维码关注公众号,回复: 12980054 查看本文章
回调队列
通常,在 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 设置某种超时吗?
- 如果服务器发生故障并引发异常,是否应该将其转发给客户端?
- 在处理之前防止无效的传入消息(如检查界限、类型)。
如果您想试验一下,可能会发现管理界面对于查看队列非常有用。