RabbitMQ 教程 - 工作队列
工作队列
（使用 amqp Elixir 库）
在第一个教程中，我们编写了程序来发送和接收来自命名队列的消息。在本教程中，我们将创建一个工作队列，用于在多个工作者之间分配耗时的任务。
工作队列（又名：任务队列）背后的主要思想是避免立即执行资源密集型任务，并避免必须等待其完成。相反，我们计划稍后完成任务。我们将任务封装为消息并将其发送到队列。在后台运行的工作进程将弹出任务并最终执行作业。当您运行多个工作进程时，任务将在它们之间共享。
这个概念在 Web 应用程序中尤其有用，在 Web 应用程序中，在短暂的 HTTP 请求窗口期间处理复杂任务是不可能的。
准备工作
在本教程的前一部分中，我们发送了一条包含“Hello World!”的消息。现在我们将发送代表复杂任务的字符串。我们没有真正的任务，例如要调整大小的图像或要渲染的 pdf 文件，所以让我们通过假装我们很忙来伪造它 - 通过使用 :timer.sleep/1 函数。我们将字符串中点的数量作为其复杂性；每个点将代表一秒钟的“工作”。例如，由 Hello... 描述的虚假任务将花费三秒钟。
我们将稍微修改上一个示例中的 send.exs 代码，以允许从命令行发送任意消息。此程序将任务调度到我们的工作队列，因此我们将其命名为 new_task.exs
message =
case System.argv do
[] -> "Hello World!"
words -> Enum.join(words, " ")
end
AMQP.Basic.publish(channel, "", "task_queue", message, persistent: true)
IO.puts " [x] Send '#{message}'"
我们旧的 receive.exs 脚本也需要进行一些更改：它需要为消息正文中的每个点伪造一秒钟的工作。它将从队列中弹出消息并执行任务，因此我们将其称为 worker.exs
defmodule Worker do
def wait_for_messages(channel) do
receive do
{:basic_deliver, payload, meta} ->
IO.puts " [x] Received #{payload}"
payload
|> to_char_list
|> Enum.count(fn x -> x == ?. end)
|> Kernel.*(1000)
|> :timer.sleep
IO.puts " [x] Done."
wait_for_messages(channel)
end
end
end
轮询分发
使用任务队列的优势之一是能够轻松地并行处理工作。如果我们正在积累大量工作，我们可以简单地添加更多工作进程，从而轻松扩展。
首先，让我们尝试同时运行两个 worker.exs 脚本。它们都将从队列中获取消息，但具体如何？让我们看看。
您需要打开三个控制台。两个将运行 worker.exs 脚本。这些控制台将是我们的两个消费者 - C1 和 C2。
mix run worker.exs
# => [*] Waiting for messages. To exit press CTRL+C, CTRL+C
mix run worker.exs
# => [*] Waiting for messages. To exit press CTRL+C, CTRL+C
在第三个控制台中，我们将发布新任务。启动消费者后，您可以发布一些消息
# shell 3
mix run new_task.exs First message.
mix run new_task.exs Second message..
mix run new_task.exs Third message...
mix run new_task.exs Fourth message....
mix run new_task.exs Fifth message.....
让我们看看交付给我们的工作进程的内容
# shell 1
mix run worker.exs
# => [*] Waiting for messages. To exit press CTRL+C, CTRL+C
# => [x] Received 'First message.'
# => [x] Received 'Third message...'
# => [x] Received 'Fifth message.....'
# shell 2
mix run worker.exs
# => [*] Waiting for messages. To exit press CTRL+C, CTRL+C
# => [x] Received 'Second message..'
# => [x] Received 'Fourth message....'
默认情况下，RabbitMQ 将按顺序将每条消息发送给下一个消费者。平均而言，每个消费者将获得相同数量的消息。这种分发消息的方式称为轮询。用三个或更多工作进程尝试一下。
消息确认
执行任务可能需要几秒钟，因此您可能想知道，如果消费者开始一项长时间的任务并在未完全完成时终止会发生什么情况。使用我们当前的代码，一旦 RabbitMQ 将消息传递给消费者，它会立即将其标记为删除。在这种情况下，如果您终止工作进程，则刚刚处理的消息将丢失。已分派给此特定工作进程但尚未处理的所有消息也将丢失。
但是我们不想丢失任何任务。如果工作进程死掉，我们希望任务被传递给另一个工作进程。
为了确保消息永远不会丢失，RabbitMQ 支持消息确认。ack（确认）由消费者发回，以告知 RabbitMQ 已收到并处理了特定消息，并且 RabbitMQ 可以自由删除它。
如果消费者死掉（其通道关闭、连接关闭或 TCP 连接丢失）而没有发送 ack，RabbitMQ 将理解消息未完全处理，并将重新将其放入队列。如果同时还有其他消费者在线，它将快速地将其重新传递给另一个消费者。这样，您可以确保即使工作进程偶尔死掉，也不会丢失任何消息。
消费者交付确认强制执行超时（默认为 30 分钟）。这有助于检测从不确认交付的有缺陷（卡住）的消费者。您可以按照交付确认超时中所述增加此超时。
手动消息确认默认情况下处于启用状态。在之前的示例中，我们通过 no_ack: true 标志显式地将其关闭。现在是时候删除此标志并从工作进程发送适当的确认，一旦我们完成任务。
defmodule Worker do
def wait_for_messages(channel) do
receive do
{:basic_deliver, payload, meta} ->
IO.puts " [x] Received #{payload}"
payload
|> to_char_list
|> Enum.count(fn x -> x == ?. end)
|> Kernel.*(1000)
|> :timer.sleep
IO.puts " [x] Done."
AMQP.Basic.ack(channel, meta.delivery_tag)
wait_for_messages(channel)
end
end
end
AMQP.Basic.consume(channel, "hello")
使用此代码，您可以确保即使您在使用 CTRL+C 终止工作进程节点时，它正在处理消息，也不会丢失任何内容。工作进程终止后不久，所有未确认的消息都将被重新传递。
确认必须在接收交付的同一通道上发送。尝试使用不同的通道进行确认将导致通道级协议异常。请参阅关于确认的文档指南以了解更多信息。
忘记确认
错过
AMQP.Basic.ack是一个常见的错误。这是一个容易犯的错误，但后果很严重。当您的客户端退出时，消息将被重新传递（这可能看起来像是随机重新传递），但 RabbitMQ 将占用越来越多的内存，因为它将无法释放任何未确认的消息。为了调试这种错误，您可以使用
rabbitmqctl打印messages_unacknowledged字段sudo rabbitmqctl list_queues name messages_ready messages_unacknowledged在 Windows 上，删除 sudo
rabbitmqctl.bat list_queues name messages_ready messages_unacknowledged
消息持久性
我们已经了解了如何确保即使消费者死掉，任务也不会丢失。但是，如果 RabbitMQ 服务器停止，我们的任务仍然会丢失。
当 RabbitMQ 退出或崩溃时，它会忘记队列和消息，除非您告诉它不要忘记。要确保消息不会丢失，需要做两件事：我们需要将队列和消息都标记为持久。
首先，我们需要确保队列在 RabbitMQ 节点重启后仍然存在。为了做到这一点，我们需要将其声明为持久
AMQP.Queue.declare(channel, "hello", durable: true)
虽然此命令本身是正确的，但在我们的设置中它不起作用。这是因为我们已经定义了一个名为 hello 的队列，它不是持久的。RabbitMQ 不允许您使用不同的参数重新定义现有队列，并且会向任何尝试执行此操作的程序返回错误。但是有一个快速的解决方法 - 让我们声明一个具有不同名称的队列，例如 task_queue
AMQP.Queue.declare(channel, "task_queue", durable: true)
这个 AMQP.Queue.declare 更改需要应用于生产者和消费者代码。
在那时，我们确信即使 RabbitMQ 重新启动，task_queue 队列也不会丢失。现在我们需要将我们的消息标记为持久
- 通过提供
persistent: true属性。
AMQP.Basic.publish(channel, "", "task_queue", message, persistent: true)
关于消息持久性的注意事项
将消息标记为持久性并不能完全保证消息不会丢失。虽然它告诉 RabbitMQ 将消息保存到磁盘，但仍然有一个短暂的时间窗口，在此期间 RabbitMQ 已经接受了消息但尚未保存它。此外，RabbitMQ 不会为每条消息执行
fsync(2)-- 它可能只是保存到缓存而不是真正写入磁盘。持久性保证并不强，但对于我们简单的任务队列来说已经足够了。如果您需要更强的保证，那么您可以使用发布者确认。
公平分发
您可能已经注意到，分发仍然无法完全按照我们的意愿工作。例如，在有两个工作进程的情况下，当所有奇数消息都很重而偶数消息都很轻时，一个工作进程将一直很忙，而另一个工作进程几乎不做任何工作。好吧，RabbitMQ 对此一无所知，仍然会均匀地分发消息。
发生这种情况是因为 RabbitMQ 只是在消息进入队列时分发消息。它不查看消费者的未确认消息的数量。它只是盲目地将每第 n 条消息分发给第 n 个消费者。
为了克服这个问题，我们可以将 AMQP.Basic.qos 函数与 prefetch_count: 1 设置一起使用。这告诉 RabbitMQ 一次不要给一个工作进程超过一条消息。或者，换句话说，在工作进程处理并确认上一条消息之前，不要向其分发新消息。相反，它会将其分发给下一个尚未忙碌的工作进程。
AMQP.Basic.qos(channel, prefetch_count: 1)
关于队列大小的注意事项
如果所有工作进程都很忙，您的队列可能会填满。您需要注意这一点，也许可以添加更多工作进程，或者使用消息 TTL。
整合在一起
我们的 new_task.exs 脚本的最终代码
{:ok, connection} = AMQP.Connection.open
{:ok, channel} = AMQP.Channel.open(connection)
AMQP.Queue.declare(channel, "task_queue", durable: true)
message =
case System.argv do
[] -> "Hello World!"
words -> Enum.join(words, " ")
end
AMQP.Basic.publish(channel, "", "task_queue", message, persistent: true)
IO.puts " [x] Sent '#{message}'"
AMQP.Connection.close(connection)
以及我们的工作进程
defmodule Worker do
def wait_for_messages(channel) do
receive do
{:basic_deliver, payload, meta} ->
IO.puts " [x] Received #{payload}"
payload
|> to_char_list
|> Enum.count(fn x -> x == ?. end)
|> Kernel.*(1000)
|> :timer.sleep
IO.puts " [x] Done."
AMQP.Basic.ack(channel, meta.delivery_tag)
wait_for_messages(channel)
end
end
end
{:ok, connection} = AMQP.Connection.open
{:ok, channel} = AMQP.Channel.open(connection)
AMQP.Queue.declare(channel, "task_queue", durable: true)
AMQP.Basic.qos(channel, prefetch_count: 1)
AMQP.Basic.consume(channel, "task_queue")
IO.puts " [*] Waiting for messages. To exit press CTRL+C, CTRL+C"
Worker.wait_for_messages(channel)
使用消息确认和 prefetch_count，您可以设置工作队列。持久性选项使任务即使在 RabbitMQ 重新启动后也能幸存。
现在我们可以继续学习教程 3，了解如何将同一消息传递给多个消费者。