基于队列的处理答案

【问题标题】：Queue based processing基于队列的处理
【发布时间】：2015-10-07 09:46:44
【问题描述】：

所以我一直在研究构建一个依赖于类似于消息传递总线的应用程序。这个想法是非常容错的。我有一个需要执行的任务队列，以下是我认为是基于队列的系统的最终目标的步骤。

现在发生了两种情况之一：

- 或 -

我正在研究不同的解决方案，我看到很多人使用 REDIS 作为后端来执行此操作，但它的队列相当简单。例如RPOPLPUSH 将从队列中删除密钥。如果服务器崩溃了怎么办？队列现在认为它处理了该项目，我们有一个丢失的任务。

建议采取哪些步骤来确保任务完成，并注意任务失败以便能够由另一台服务器重新处理？我打算在 go 中编写任务，并且我愿意使用 AWS 等云服务。

【问题讨论】：

RPOPLPUSH 确实在一个原子操作中出列和重新入列到另一个列表。如果您的进程在此操作后失败，则不会丢失任何内容（该项目仍存在于其他列表中）。也就是说，使用 Redis 实现真正的保证交付并非易事。
@DidierSpezia 您还有其他解决方案吗？
真正的排队系统可能正是您所寻找的。请参阅 RabbitMQ、ActiveMQ 等...这是 RabbitMQ Go 客户端：github.com/streadway/amqp
@DidierSpezia 把它变成一个答案，我会给你我的赞许。
如果你想要一个轻量级的非分布式工作队列，beantalkd 会满足你的要求kr.github.io/beanstalkd

【解决方案1】：

Redis 是一个基本组件，您可以在其上构建队列系统。也就是说，在 Redis 之上实现一个真正有保障的交付系统并非易事，尤其是在您需要事务行为的情况下。

以下是一些使用 Redis 以各种语言实现的排队系统：

在 Go 中可以开发类似的东西，但是当涉及到真正的保证交付语义时，细节就是魔鬼。

专用队列系统（例如 RabbitMQ 或 ActiveMQ）可能会为您提供更好的服务。虽然它们更复杂，但它们提供了更多功能，并且可能提供了更好的保证。

这是 RabbitMQ 的 Go 客户端：https://github.com/streadway/amqp

您可能也有兴趣查看disque（Redis 作者的专用队列解决方案）和https://github.com/EverythingMe/go-disque 的相应 Go 客户端

最后，beanstalkd 是另一个轻量级的解决方案；您可以在以下位置找到 Go 客户端：https://github.com/kr/beanstalk

【讨论】：

【解决方案2】：

可能会在这里说明显而易见的情况，但 SQS (http://aws.amazon.com/sqs/) 可以为您提供开箱即用的所需内容。您无需担心管理排队系统，它会自动为您扩展，您将专注于编写应用程序。

您将消息推送到队列。工作人员将它们从队列中拉出，处理它们并在完成后确认消息。如果工作人员在超时后未确认消息，则您指定的消息将浮出水面给另一个工作人员。

【讨论】：

我担心多个工作人员可以通过 SQS 接收消息。队列的重点是一个工作人员应该同时处理一项任务。不知道为什么亚马逊允许多个工人从事同一个任务。
假定消息未处理（删除），SQS 中的消息在被传递到第二个队列工作程序之前会被设置一个超时时间。
@FrankerZ 在正常操作中，您将有一名工作人员处理消息。无论如何，您都需要处理 2 个具有相同消息的工作人员，以防工作人员花费的时间超过超时时间并将消息提供给第 2 个工作人员。
后退一步：在存在故障客户端/网络/服务器的情况下，保证一次性交付非常困难（即不可能）。要走的路是实际使您正在制作的操作的效果具有幂等性，因此第二个客户端处理相同的消息不会造成伤害。你可以弄清楚它的粒度（即只要你有检查点，并不是所有的动作都必须是幂等的）