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具有最佳结果，但如前所述，可能不是高访问者数量的最佳解决方案。 此外，您不应忘记在jobs表中仍然存在insert 。
3. 令我惊讶的是， AWS SQS比使用数据库慢。 我猜这是因为对于database您已经建立了与连接池中数据库的连接，但SQS必须每次都建立TLS连接。 因此，额外300-400ms。

老实说，我不认为SQS很难设置（只需按照指南 ）。 我认为该决定取决于您的访客号码。