轻松搞定RabbitMQ（七）——远程过程调用RPCClient interface（客户端接口）Callback queue（回调队列）Message properties（消息属性）Correlation IdSummary（总结）完整的实例

       翻译：http://www.rabbitmq.com/tutorials/tutorial-six-java.html

       在第二篇博文中，我们已经了解到了如何使用工作队列来向多个消费者分散耗时任务。

       但是付过我们需要在远程电脑上运行一个方法然后等待结果，该怎么办？这是不同的需求。这个模式通常叫做RPC。

       本文我们将使用RabbitMQ构建一个RPC系统：一个客户端和一个可扩展的RPC服务器端。由于我们没有任何真实的耗时任务需要分配，所以我们将创建一个虚拟的RPC服务，可以返回斐波纳契数列。

       为了说明RPC服务可以使用，我们创建一个简单的客户端类。暴露一个方法——发送RPC请求，然后阻塞直到获得结果。

       一般在RabbitMQ中做RPC是很简单的。客户端发送请求消息，服务器回复响应的消息。为了接受响应的消息，我们需要在请求消息中发送一个回调队列。可以用默认的队列（仅限java客户端）。试一试吧：

       AMQP协议为消息预定义了一组14个属性。大部分的属性是很少使用的。除了一下几种：

deliveryMode：标记消息传递模式，2-消息持久化，其他值-瞬态。在第二篇文章中还提到过。

contentType：内容类型，用于描述编码的mime-type。例如经常为该属性设置JSON编码。

replyTo：应答，通用的回调队列名称

correlationId：关联ID，方便RPC响应与请求关联

       我们需要添加一个新的导入

       在上述方法中为每个RPC请求创建一个回调队列。这是很低效的。幸运的是，一个解决方案：可以为每个客户端创建一个单一的回调队列。

       新的问题被提出，队列收到一条回复消息，但是不清楚是那条请求的回复。这是就需要使用correlationId属性了。我们要为每个请求设置唯一的值。然后，在回调队列中获取消息，看看这个属性，关联response和request就是基于这个属性值的。如果我们看到一个未知的correlationId属性值的消息，可以放心的无视它——它不是我们发送的请求。

       你可能问道，为什么要忽略回调队列中未知的信息，而不是当作一个失败？这是由于在服务器端竞争条件的导致的。虽然不太可能，但是如果RPC服务器在发送给我们结果后，发送请求反馈前就挂掉了，这有可能会发送未知correlationId属性值的消息。如果发生了这种情况，重启RPC服务器将会重新处理该请求。这就是为什么在客户端必须很好的处理重复响应，RPC应该是幂等的。

       我们的RPC的处理流程：

当客户端启动时，创建一个匿名的回调队列。

客户端为RPC请求设置2个属性：replyTo，设置回调队列名字；correlationId，标记request。

请求被发送到rpc_queue队列中。

RPC服务器端监听rpc_queue队列中的请求，当请求到来时，服务器端会处理并且把带有结果的消息发送给客户端。接收的队列就是replyTo设定的回调队列。

客户端监听回调队列，当有消息时，检查correlationId属性，如果与request中匹配，那就是结果了。

RPC服务器端（RPCServer.java）

RPC客户端（RPCClient.java）：

输出结果：