Laravel Queue，Beanstalkd vs Database，有什么区别？

Question

使用 Beanstalkd 和队列的数据库驱动程序有很大区别吗？

一些优点和缺点是什么？数据库队列似乎更容易设置和运行，使用它我应该知道什么？

文档中没有关于它的真正解释。

Answer 1

使用数据库作为队列可以更简单地设置并且可能更容易在开发机器上进行测试。但是在生产环境中将数据库作为队列运行可能不是一个好主意。尤其是在人流量大的情况下。虽然数据库可能不是用于排队的正确工具，但让我们看看使用它的利弊。

优点：

• 更容易设置
• 如果您使用相同的数据库，可能会减少应用程序中移动部件的数量

缺点：

• 对于大量的读取和写入，必须有某种机制来锁定行和更新索引等。
• 轮询工作人员也会锁定一个索引，以便对其进行处理，并使用作业的最终状态更新行。
• 在这种情况下，对 DB 的写入可能会排队并需要更长的时间才能执行。

SQS、Beanstalkd、RabbitMQ 等消息队列是为处理这些场景而构建的。因为他们只关心消息被存储和处理，所以他们不必担心锁定和事务日志（这是数据库所需要的）。将消息队列添加到您的系统将有助于它更轻松地扩展。此外，它还允许数据库进行实际事务处理而无需担心消息传递，从而让数据库呼吸。

Answer 2

我在我的一台生产服务器上做了一些测试。

场景：Insert a new visitor tracking info (ip, city, state, country, lat, lng, user-agent, etc)（要插入新条目，您需要确保IP在过去 24 小时内没有访问过），所以它也有一个select 查询。

（注意：表大小以百万为单位，实例为micro，只是看看最坏的情况是什么）

这是我得到的数字：

|--------------|----------|----------|
| Queue Driver |  TTFB    | Blocking |
|--------------|----------|----------|
| Sync         | 2.130sec | YES      |
| Database     | 0.430sec | NO       |
| AWS SQS      | 0.855sec | NO       |
|--------------|----------|----------|

1. 显然，sync 是最糟糕的选择，因为用户必须坐在那里 2.3 秒才能开始接收任何数据。
2. database 的结果最好，但如前所述，可能不是高访问量的最佳解决方案。此外，您不应该忘记，insert 仍然存在于 jobs 表中。
3. AWS SQS 令我惊讶的是比使用数据库要慢。我猜这是因为database 已经在连接池中建立了与数据库的连接，但是SQS 每次都必须建立TLS 连接。因此，额外的 300-400 毫秒。

老实说，我不认为SQS 很难设置（只需遵循guide）。我认为该决定取决于您的访客人数。