2019年12月10日10:05:54
原文：https://www.rabbitmq.com/tutorials/tutorial-six-php.html
远程过程调用（RPC）
（使用php-amqplib）
先决条件
本教程假定RabbitMQ 已在标准端口（5672）的本地主机上安装并运行。如果您使用其他主机，端口或凭据，则连接设置需要进行调整。
在哪里获得帮助
如果您在阅读本教程时遇到困难，可以 通过邮件列表与我们联系。
在第二篇教程中，我们学习了如何使用工作队列在多个工作人员之间分配耗时的任务。
但是，如果我们需要在远程计算机上运行功能并等待结果怎么办？好吧，那是一个不同的故事。这种模式通常称为“ 远程过程调用”或“ RPC”。
在本教程中，我们将使用RabbitMQ构建RPC系统：客户端和可伸缩RPC服务器。由于我们没有值得分配的耗时任务，因此我们将创建一个虚拟RPC服务，该服务返回斐波那契数。
客户端界面
为了说明如何使用RPC服务，我们将创建一个简单的客户端类。它将公开一个名为call的方法，该方法 发送RPC请求并阻塞，直到收到答案为止：
$ fibonacci_rpc = 新的 FibonacciRpcClient（）; $ response = $ fibonacci_rpc-> call（30）; echo '[。] Got'，$ response，“ \ n” ;
有关RPC的说明
尽管RPC是计算中非常普遍的模式，但它经常受到批评。当程序员不知道函数调用是本地的还是缓慢的RPC时，就会出现问题。这样的混乱会导致系统变幻莫测，并给调试增加了不必要的复杂性。滥用RPC可能会导致无法维护的意大利面条代码，而不是简化软件。
牢记这一点，请考虑以下建议：
- 确保明显的是哪个函数调用是本地的，哪个是远程的。
- 记录您的系统。明确组件之间的依赖关系。
- 处理错误案例。RPC服务器长时间关闭后，客户端应如何反应？
如有疑问，请避免使用RPC。如果可以的话，应该使用异步管道-代替类似RPC的阻塞，将结果异步推送到下一个计算阶段。
回调队列
通常，通过RabbitMQ进行RPC很容易。客户端发送请求消息，服务器发送响应消息。为了接收响应，我们需要发送带有请求的“回调”队列地址。我们可以使用默认队列。让我们尝试一下：
list（$ queue_name，，）= $ channel-> queue_declare（“”，false，false，true，false）;
$ msg = 新的 AMQPMessage（
$ payload，
数组（'reply_to' => $ queue_name）
）;
$ channel-> basic_publish（$ msg，``，'rpc_queue'）;
＃...然后编写代码以从callback_queue中读取响应消息...
邮件属性
AMQP 0-9-1协议预定义了消息附带的14个属性集。除以下属性外，大多数属性很少使用：
- delivery_mode：将消息标记为持久消息（值为2）或瞬态消息（1）。您可能还记得第二个教程中的此属性。
- content_type：用于描述编码的mime类型。例如，对于经常使用的JSON编码，将此属性设置为application / json是一个好习惯。
- reply_to：通常用于命名回调队列。
- related_id：用于将RPC响应与请求相关联。
关联ID
在上面介绍的方法中，我们建议为每个RPC请求创建一个回调队列。那是相当低效的，但是幸运的是有更好的方法-让我们为每个客户端创建一个回调队列。
这引起了一个新问题，在该队列中收到响应后，尚不清楚响应属于哪个请求。那就是使用correlation_id属性的时候 。我们将为每个请求将其设置为唯一值。稍后，当我们在回调队列中收到消息时，我们将查看该属性，并基于此属性将响应与请求进行匹配。如果我们看到未知的 related_id值，则可以放心地丢弃该消息-它不属于我们的请求。
您可能会问，为什么我们应该忽略回调队列中的未知消息，而不是因错误而失败？这是由于服务器端可能出现竞争状况。尽管可能性不大，但RPC服务器可能会在向我们发送答案之后但在发送请求的确认消息之前死亡。如果发生这种情况，重新启动的RPC服务器将再次处理该请求。这就是为什么在客户端上我们必须妥善处理重复的响应，并且理想情况下RPC应该是幂等的。
摘要
我们的RPC将像这样工作：
- 客户端启动时，它将创建一个匿名排他回调队列。
- 对于RPC请求，客户端发送一条具有两个属性的消息： reply_to（设置为回调队列）和correlation_id（针对每个请求设置为唯一值）。
- 该请求被发送到rpc_queue队列。
- RPC工作程序（又名：服务器）正在等待该队列上的请求。出现请求时，它会使用reply_to字段中的队列来完成工作并将带有结果的消息发送回客户端。
- 客户端等待回调队列上的数据。出现消息时，它将检查correlation_id属性。如果它与请求中的值匹配，则将响应返回给应用程序。
放在一起
斐波那契任务：
函数 fib （$ n）
{
if（$ n == 0）{
返回 0 ;
}
if（$ n == 1）{
返回 1 ;
}
返回 fib（$ n -1）+ fib（$ n -2）;
}
我们声明我们的斐波那契函数。它仅假定有效的正整数输入。（不要指望这种方法适用于大量用户，它可能是最慢的递归实现）。
我们的RPC服务器rpc_server.php的代码如下所示：
<？php
require_once __DIR__。'/vendor/autoload.php' ;
使用 PhpAmqpLib \ Connection \ AMQPStreamConnection ;
使用 PhpAmqpLib \ Message \ AMQPMessage ;
$ connection = new AMQPStreamConnection（'localhost'，5672，'guest'，'guest'）;
$ channel = $ connection-> channel（）;
$ channel-> queue_declare（'rpc_queue'，false，false，false，false）;
函数 fib （$ n）
{
if（$ n == 0）{
返回 0 ;
}
if（$ n == 1）{
返回 1 ;
}
返回 fib（$ n -1）+ fib（$ n -2）;
}
echo “ [x]等待RPC请求\ n” ;
$ callback = 函数 （$ req） {
$ n = intval（$ req-> body）;
回声 '[。] fib（'，$ n，“）\ n” ;
$ msg = 新的 AMQPMessage（
（字符串）fib（$ n），
数组（'correlation_id' => $ req-> get（'correlation_id'））
）;
$ req-> delivery_info [ 'channel' ]-> basic_publish（
$ msg，
''，
$ req-> get（'reply_to'）
）;
$ req-> delivery_info [ 'channel' ]-> basic_ack（
$ req-> delivery_info [ 'delivery_tag' ]
）;
};
$ channel-> basic_qos（null，1，null）;
$ channel-> basic_consume（'rpc_queue'，''，false，false，false，false，$ callback）;
而（$ channel-> is_using（））{
$ channel-> wait（）;
}
$ channel-> close（）;
$ connection-> close（）;
服务器代码非常简单：
- 像往常一样，我们首先建立连接，通道并声明队列。
- 我们可能要运行多个服务器进程。为了将负载平均分配到多个服务器上，我们需要在$ channel.basic_qos中设置 prefetch_count设置。
- 我们使用basic_consume访问队列。然后，我们进入while循环，在其中等待请求消息，进行工作并将响应发送回去。
我们的RPC客户端rpc_client.php的代码：
<？php
require_once __DIR__。'/vendor/autoload.php' ;
使用 PhpAmqpLib \ Connection \ AMQPStreamConnection ;
使用 PhpAmqpLib \ Message \ AMQPMessage ;
FibonacciRpcClient
类 {
private $ connection;
私人 $ channel;
私人 $ callback_queue;
私人 $回应；
私人 $ corr_id;
公共 功能 __construct （）
{
$ this- > connection = new AMQPStreamConnection（
'localhost'，
5672，
'guest'，
'guest'
）;
$ this- > channel = $ this- > connection-> channel（）;
list（$ this- > callback_queue，，）= $ this-> channel-> queue_declare（
“”，
false，
false，
true，
false
）;
$ this-> channel-> basic_consume（$ this-
> callback_queue，
``，
false，
true，
false，
false，
array（
$ this，
'onResponse'
）
）;
}
公共 功能 onResponse （$ rep）
{
if（$ rep- > get（'correlation_id'）== $ this-> corr_id）{ $ this-
> response = $ rep-> body;
}
}
公共 功能 调用（$ n）
{
$ this- > response = null ;
$ this-> corr_id = uniqid（）;
$ msg = 新的 AMQPMessage（
（字符串）$ n，
数组（
'correlation_id' => $ this-> corr_id，'reply_to' => $ this-
> callback_queue
）
）;
$ this-> channel-> basic_publish（$ msg，``，'rpc_queue'）;
while（！$ this-> response）{
$ this-> channel-> wait（）;
}
返回 intval（$ this- > response）;
}
}
$ fibonacci_rpc = 新的 FibonacciRpcClient（）;
$ response = $ fibonacci_rpc-> call（30）;
echo '[。] Got'，$ response，“ \ n” ;
现在是时候看看rpc_client.php和rpc_server.php的完整示例源代码了 。
我们的RPC服务现已准备就绪。我们可以启动服务器：
php rpc_server.php ＃=> [x]等待RPC请求
要请求斐波那契编号，请运行客户端：
php rpc_client.php ＃=> [x]请求fib（30）
这里介绍的设计不是RPC服务的唯一可能的实现，但是它具有一些重要的优点：
- 如果RPC服务器太慢，则可以通过运行另一台RPC服务器来扩大规模。尝试在新控制台中运行另一个rpc_server.php。
- 在客户端，RPC只需要发送和接收一条消息。不需要诸如queue_declare之 类的同步调用。结果，RPC客户端只需要一个网络往返就可以处理单个RPC请求。
我们的代码仍然非常简单，并且不会尝试解决更复杂（但很重要）的问题，例如：
- 如果没有服务器在运行，客户端应该如何反应？
- 客户端是否应该为RPC设置某种超时时间？
- 如果服务器发生故障并引发异常，是否应该将其转发给客户端？
- 在处理之前防止无效的传入消息（例如检查边界，类型）。
如果要进行实验，可能会发现管理UI对于查看队列很有用。
来源：https://www.cnblogs.com/zx-admin/p/12015000.html