在第二个教程中，我们学习了如何使用工作队列在多个工作人员之间分配耗时的任务。
但是如果我们需要在远程计算机上运行一个函数并等待结果呢？好吧，那是另一回事了。这种模式通常称为远程过程调用或RPC。
在本教程中，我们将使用RabbitMQ构建一个RPC系统：一个客户端和一个可伸缩的RPC服务器。由于我们没有任何值得分发的耗时任务，我们将创建一个返回Fibonacci数的虚拟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是很容易的。客户端发送请求消息，服务器用响应消息进行响应。为了接收响应，我们需要将“回调”队列地址与请求一起发送。我们可以使用默认队列（在Java客户端中是独占的）。让我们试试：
callbackQueueName = channel.queueDeclare().getQueue();
BasicProperties props = new BasicProperties
.Builder()
.replyTo(callbackQueueName)
.build();
channel.basicPublish("", "rpc_queue", props, message.getBytes());
// ... then code to read a response message from the callback_queue ...
消息属性
AMQP 0-9-1协议预先定义了一组14个属性，这些属性与消息一起使用。除以下情况外，大多数属性很少使用：
- deliveryMode：将消息标记为持久（值为2）或临时（任何其他值）。您可能记得第二个教程中的这个属性。
- 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);
}
我们声明了fibonacci函数。它假设只有有效的正整数输入。（不要指望这个方法能处理大数据，而且它可能是最慢的递归实现）。
我们的RPC服务器的代码可以在这里找到：RPCServer.java.
服务器代码相当简单：
- 像往常一样，我们从建立连接、通道和声明队列开始。
- 我们可能需要运行多个服务器进程。为了在多个服务器上平均分配负载，我们需要在channel.basicQos中设置prefetchCount.
- 我们使用basicConsume来访问队列，在basicConsume方法的参数中中我们以一个对象（DeliverCallback）的形式提供一个回调，该对象将执行工作并将响应发回。
我们的RPC客户端的代码可以在这里找到：RPCClient.java.
客户端代码稍微更复杂一些：
- 我们建立了连接和通道。
- 我们的call方法产生实际的RPC请求。
- 在这里，我们首先生成一个唯一的correlationId号并保存它-我们的消费者回调将使用这个值来匹配适当的响应。
- 然后，我们为应答创建一个专用的独占队列并订阅它。
- 接下来，我们发布请求消息，包含两个属性：replyTo和correlationId。
- 在这一点上，我们可以坐下来，等待正确的响应到来。
- 因为我们的消费者交付处理是在一个单独的线程中进行的，所以在响应到达之前，我们需要一些东西来挂起主线程。使用BlockingQueue是一种可能的解决方案。这里我们创建的ArrayBlockingQueue的容量设置为1，因为我们只需要等待一个响应。
- 消费者正在做一个非常简单的工作，对于每个被消费的响应消息，它都会检查correlationId是否就是我们要查找的那个。如果是这样，它将响应放入BlockingQueue。
- 同时，主线程正在等待从BlockingQueue获取响应。
- 最后，我们将响应返回给用户。
向客户发出请求：
RPCClient fibonacciRpc = new RPCClient();
System.out.println(" [x] Requesting fib(30)");
String response = fibonacciRpc.call("30");
System.out.println(" [.] Got '" + response + "'");
fibonacciRpc.close();
像往常一样编译并设置类路径（参见教程一）：
javac -cp $CP RPCClient.java RPCServer.java
我们的RPC服务现在准备好了。我们可以启动服务器：
java -cp $CP RPCServer
# => [x] Awaiting RPC requests
要请求fibonacci数列，请运行客户端：
java -cp $CP RPCClient
# => [x] Requesting fib(30)
这里介绍的设计并不是RPC服务的唯一可能实现，但它有一些重要的优点：
- 如果RPC服务器太慢，您可以通过运行另一个服务器来扩展。尝试在新控制台中运行第二个RPCServer。
- 在客户端，RPC只需要发送和接收一条消息。不需要像queueDeclare这样的同步调用。因此，RPC客户机只需要为单个RPC请求进行一次网络往返。
我们的代码仍然非常简单，不试图解决更复杂（但很重要）的问题，例如：
- 如果没有服务器在运行，客户机应该如何反应？
- 客户端应该为RPC设置某种超时吗？
- 如果服务器发生故障并引发异常，是否应将其转发给客户端？
- 在处理之前防止无效的传入消息（如检查边界、类型）。