Redis 8 发布了——而且是开源的
了解更多
分享由 Eli Skeggs（[email protected]）原创发布
我们很高兴宣布 v1.0 版本的 Bee-Queue：一个快速、轻量级、健壮的基于 Redis 的 Node.js 作业队列。在 Bee-Queue 原始作者 Lewis Ellis 的帮助下，我们重振了这个项目，使其成为 Node 生态系统中速度最快、最健壮的基于 Redis 的分布式队列。Mixmax 正在生产环境中使用 Bee-Queue 来处理每天 数千万 个作业。
Bee-Queue 旨在为分布式工作池提供动力，并且在构建时考虑了短时的实时作业。扩展非常简单，只需运行更多的工作进程，Bee-Queue 甚至还有一个有用的 交互式仪表板，我们使用它来直观地监控作业处理。
以下是 Bee-Queue v1.0 与 Node 生态系统中的其他基于 Redis 的作业队列（包括其自身的先前 v0.x 版本）的比较
那么，为什么 Node.js 生态系统中还需要另一个作业队列呢？到目前为止，Mixmax 一直在使用类似的队列 Bull。 Bull 为我们服务了一年，但是存在一个竞争条件，导致某些作业被双重处理，从而在大规模时引起重大问题。该竞争条件已在 Bull v3 中修复，但不幸的是，v3 也经历了相对于 v2 的显着 性能下降。我们面临着完全迁移到其他队列（例如 RabbitMQ）或重新开始编写我们自己的简单高性能的基于 Redis 的队列的决定。
我们决定坚持使用 Redis 而不是其他消息传递框架（例如 RabbitMQ），因为它易于使用且可以以低成本获得更高的性能。借助 Redis，我们可以轻松扩展我们的 Redis 集群以满足我们不断增长的需求，现在每小时处理数千万个作业。 Redis 还使我们能够将流量保持在我们的网络 VPC 内部，这是我们所有敏感数据的核心安全要求。我们是 Mixmax 的 Redis 的忠实拥护者，因此团队中的每个人都有使用它的经验。
考虑到这一点，我们决定构建我们自己的基于 Redis 的轻量级队列，该队列仅执行我们需要的操作，以便优先考虑性能。在从头开始该项目之前，我们重新发现了 Bee-Queue，几年前就已经看到过它。我们再次评估了其代码库，并很快意识到这将是一个很好的构建平台。在现有队列的基础上进行构建节省了我们数周的实施时间；我们刷新了代码库，确定了我们缺少的特性，并在原始作者 Lewis 的帮助下 添加了这些特性。
我们本周发布了 Bee-Queue v1.0，并已切换为完全使用它而不是 Bull。我们所有的生产流量现在都通过 Bee-Queue 流动，并且我们没有发现任何问题。资源使用率已大大降低，通过降低 Node.js 和需要更少的 Redis 资源来衡量。我们还可以重新利用我们 Bull 时代的现有 工具来与 Bee-Queue 一起使用。构建 Bee-Queue 以满足我们的需求最终花费的时间最少，因为我们不需要重写任何应用程序代码，甚至不需要更改我们现有的监控基础架构，该基础架构已经构建在 Redis 之上。
Bee-Queue 现在托管在一个新的 Github 组织中，我们与 Lewis 共同维护它。我们鼓励您查看并贡献，或者，如果您正在寻找功能更完善的队列，请查看 Bull。我们使用 Bee-Queue 的目标是使其保持小巧，并将性能和稳定性作为首要任务。
如果您是 Redis 的粉丝并且喜欢解决这些问题，请与我们一起工作！ mixmax.com/careers
