前端开发人员的前6个排队系统

您正在寻找一个排队系统吗？或者您正在寻找一个更好的排队系统？这里有您需要的所有信息！

排队系统是后端开发的最好保密。

不想试着写一首赞美排队系统的诗，我会说，当一名初级后端开发人员学会将队列集成到系统中后，他就会成为一个中级后端开发人员。队列可以提高客户体验（我们将看到如何做到），减少复杂性，并提高系统的可靠性。

当然，对于非常简单的Web应用程序和近乎零流量和介绍网站来说，队列可能是整体的（或者甚至是不可能安装的，如果您在传统环境下无法安装），但是非平凡的应用程序都会从队列系统中受益，而且大型应用程序在没有排队参与的情况下是不可能的。

在我们开始之前，免责声明：如果您已经熟悉了排队系统并希望比较不同的选择，下面的几个介绍性部分会让您昏昏欲睡。所以请随意跳过。这些介绍性部分是为那些对排队系统只有一个模糊概念或仅仅听过名字的人准备的。

什么是排队系统？

让我们从了解什么是队列开始。

队列是计算机科学中的一种数据结构，模仿我们周围看到的现实世界队列。例如，如果您去售票窗口，您会注意到您必须站在队列的末尾，而队列开头的人会首先得到票。这也是我们所说的“先来先服务”现象。在计算机科学中，我们可以编写将任务像这样存储在队列中的程序，按照“先来先服务”的原则逐个处理它们。

请注意，队列本身不进行任何实际处理。它只是一种类似临时存储的地方，任务在那里等待直到被某个处理它们的东西接收。如果这听起来有点太抽象，别担心。这是一个抽象的概念，但我们将在下一节中看到明确的例子。：）

为什么您需要排队系统？

不用进行非常冗长的描述，我会说排队系统的主要需求是因为后台处理、并行执行和故障恢复。让我们通过示例来看看这些：

后台处理

假设您正在运行一个时间非常紧迫的营销活动，并且您的应用程序构建得可以在客户完成付款并显示“感谢您”页面之前发送确认电子邮件。如果您连接的邮件服务器关闭，Web页面将直接死掉，破坏了用户体验。

想象一下您将收到大量的支持请求！在这种情况下，更好的方法是将此发送电子邮件的任务推送到作业队列，并向客户显示成功页面。

并行执行

许多开发人员，尤其是那些主要编写简单、低流量应用程序的人，习惯于使用后台处理。这很好，直到输入的大小变得太大而无法清除为止。例如，假设您有一个定期作业，编译分析报告并将其通过电子邮件发送给用户，您的系统每分钟可以处理100份报告。

一旦您的应用程序增长并且平均每分钟处理超过100个请求，它将越来越落后，并且永远无法完成所有工作。

在排队系统中，可以通过设置多个工作进程来避免这种情况，每个进程可以选择一个任务（每个任务包含100个报告），并并行工作以更快地完成任务。

从故障中恢复

我们通常不会将网络故障和API的停机视为网页开发的失败。我们习以为常，我们的服务器和我们使用的API将始终在线。但现实是不同的-网络故障非常普遍，您依赖的优秀API可能由于基础设施问题而停机（在您说“不是我！”之前，请不要忘记massive Amazon S3 outage）。因此，回到报告示例，如果您的报告生成的一部分需要连接到支付API，并且该连接断开了2分钟，那200份报告会发生什么情况？

然而，队列系统确实涉及相当大的开销。由于您进入了一个全新的领域，应用程序和部署的复杂性增加，排队作业并不总是可以100%精确地控制。尽管如此，有时构建一个没有队列的应用程序是不可能的。

在这些问题解决之后，让我们来看一下当今排队后端/系统中的一些常见选项。

Redis

Redis被称为一个仅存储、更新和检索数据字符串而不了解数据结构的键值存储。虽然这在以前可能是真的，但今天Redis具有高效和非常有用的数据结构，如列表、有序集合，甚至还有发布-订阅系统，使其非常适合队列实现。

Redis的优点包括：

完全内存数据库，读写速度更快。
高效：可以轻松支持每秒超过100,000次的读写操作。
高度灵活的持久性方案。您可以选择在性能最大化的情况下可能发生数据丢失，或者以完全保守的方式设置以换取性能。
支持集群

请注意，Redis没有任何消息/队列/恢复抽象层，因此您需要使用一个包或构建一个轻量级系统。一个例子是Redis是Laravel的默认队列后端PHP framework，框架作者已经实现了一个调度器。

Learning Redis很容易。

RabbitMQ

Redis和RabbitMQ之间有一些微妙的差别，所以我们首先来解决它们。

首先，RabbitMQ有一个更专门、更明确的角色，因此它的构建反映了这一点-消息。换句话说，它的优势在于充当两个系统之间的中介者，而这对于Redis来说不是这样，Redis充当数据库。因此，RabbitMQ提供了一些在Redis中缺失的其他功能：消息路由，重试，负载分配等。

如果您仔细考虑一下，任务队列也可以被视为一个消息传递系统，其中调度器、工作人员和工作“提交者”可以被视为参与消息传递的实体。

RabbitMQ具有以下优点：

更好的消息传递抽象，如果您需要消息传递，则减少应用程序级别的工作。
比Redis更能承受停电和故障（至少默认情况下）。
支持分布式部署的集群和联邦支持。
有助于管理和监控部署的实用工具。
支持几乎所有非平凡的编程语言。
可以使用您选择的工具进行部署（Docker，Chef，Puppet等）。

何时使用RabbitMQ？我会说，当您知道需要使用异步消息传递，但又不准备解决此列表中其他排队选项的复杂性时，RabbitMQ是一个很好的选择（请参见下文）。

ActiveMQ

如果您从事企业领域（或正在构建高度分布式和大规模应用程序），并且不希望一直重复造轮子（并在过程中犯错误），那么值得一看ActiveMQ。

这里是ActiveMQ的优点：

它是用Java实现的，因此具有非常好的Java集成（遵循JMS标准）。
支持多种协议：AMQP，MQTT，STOMP，OpenWire等。
默认支持安全性，路由，消息过期，分析等功能。
内置支持流行的分布式消息传递模式，节省时间和成本。

这并不意味着ActiveMQ只适用于Java。它还有Python，C/C ++，Node，.Net和其他生态系统的客户端，因此将来可能不会出现问题。此外，ActiveMQ是建立在完全开放的标准上的，因此构建自己的轻量级客户端应该很容易。

尽管如此，请注意ActiveMQ只是一个代理商，不包括后端。您仍然需要使用其中一个支持的后端来存储消息。我在这里包括它是因为它不受特定编程语言的限制（例如其他流行解决方案如Celery，Sidekiq等）

Amazon MQ

Amazon MQ在这里值得快速但重要的提到。如果您认为ActiveMQ是您的理想解决方案，但不想自己构建和维护基础设施，Amazon MQ提供了一个托管服务来做到这一点。它支持ActiveMQ使用的所有协议 – 功能上没有任何区别 – 因为它在内部使用ActiveMQ本身。

优点在于它是一个托管服务，所以您只需要担心使用它。对于那些部署在AWS上的部署来说，这更有意义，因为您可以直接利用部署内的其他服务和优惠（例如更快的数据传输）。

Amazon SQS

我们不能指望亚马逊在关键基础设施方面保持沉默，对吗？ 🙂

因此，我们有，这是由众所周知的AWS巨头提供的完全托管的简单队列服务。再次强调，微小的差异很重要，因此请注意SQS没有消息传递的概念。与Redis一样，它是一个简单的后端，用于接受和分发队列中的作业。

那么，何时使用Amazon SQS呢？以下是一些原因：

你是AWS的粉丝，不会碰其他任何东西（老实说，有很多人都是这样，我认为这没有错）。
您需要一个托管解决方案，以确保故障率为零，不会丢失任何作业。
您不希望构建一个集群并自己监控它。或者更糟糕的是，不得不构建监控工具，而您可以利用那些时间进行有效的开发。
您已经在AWS平台上有大量投资，并且留在其中使商业上有意义。
您希望一个专注的简单队列系统，而不涉及任何与消息传递，协议等有关的花哨东西。

总而言之，Amazon SQS对于任何希望将作业队列纳入其系统而又不必担心安装/监视等的人来说是一个可靠的选择。

Beanstalkd

Beanstalkd已经存在很长时间，是一个经过战斗测试的快速，易于使用的作业队列后端。 Beanstalkd具有一些特点，使其与Redis有很大的区别：

它严格是一个作业队列系统，没有其他功能。您将作业推送到其中，稍后由作业工作者提取。因此，如果您的应用程序甚至有一点点对消息传递的需求，您将希望避免使用Beanstalkd。
它没有像集合，优先级队列等高级数据结构。
Beanstalkd是所谓的先进先出（FIFO）队列。没有办法按优先级排列作业。
没有集群选项。

所有这些都说了，Beanstalkd对于在单个服务器上运行的简单项目来说，是一个流畅且快速的队列系统。对于许多人来说，它比Redis更快且更稳定。因此，如果您在使用Redis时遇到无法解决的问题，并且您的需求很简单，那么可以尝试使用Beanstalkd。

结论

如果您阅读到这里（或者在快速阅读中到达这里😉），那么您很有可能对队列系统感兴趣或者需要一个队列系统。如果是这样，本页面上的列表将对您有很大帮助，除非您正在寻找特定语言/框架的队列系统。

我希望我能告诉您队列是简单且100％可靠的，但事实并非如此。它很混乱，并且由于它发生在后台并且发生得非常快（错误可能不被察觉并且变得非常昂贵）。尽管如此，在某种程度上队列仍然是非常必要的，并且您会发现它们是您武器库中（甚至可能是最强大的）的有力武器。祝你好运！🙂