Database Laravel队列、Beanstalkd与数据库有什么区别？

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

有什么利弊？数据库队列似乎更容易设置和运行，关于使用它，我应该知道些什么

---

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

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

优点：

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

缺点：

• 对于大量的读写操作，必须有某种机制来锁定行和更新索引等
• 轮询工作人员还将锁定索引以便对其进行操作，并用作业的最终状态更新行
• 在这种情况下，对数据库的写入可能会排队，执行时间会更长

---

消息传递队列（如SQS、Beanstalkd、RabbitMQ等）是为处理这些场景而构建的。因为它们只关心存储和处理的消息，所以不必担心锁定和事务日志记录（这是数据库所必需的）。向系统中添加消息队列将帮助它更容易扩展。此外，它还允许数据库进行实际事务处理，而不必担心消息传递。我在一台生产服务器上做了一些测试

场景：

插入新的访客跟踪信息（ip、城市、州、国家、lat、lng、用户代理等）

（要插入新条目，您需要确保

ip

在过去24小时内没有访问过），因此它还有一个

选择

查询

（注意：表大小以百万为单位，实例为

micro

，看看最坏的情况是什么）

以下是我得到的数字：

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

显然，

sync

是最糟糕的选择，因为用户必须在开始接收任何数据之前，在那里坐上2.3秒

数据库

具有最佳效果，但如前所述，可能不是高访客数量的最佳解决方案。此外，您不应该忘记，在

作业

表中仍然有一个

插入

AWS SQS

让我惊讶的是，它比使用数据库慢。我猜这是因为使用

database

您已经在连接池中建立了到数据库的连接，但是

SQS

每次都必须建立

TLS

连接。因此，额外的300-400ms

---

老实说，我并不认为

SQS

很难设置（只需遵循以下步骤）。我认为这个决定是基于您的访客数量。

您是否将

Redis

包括在数据库类别中？事实上，Redis有特殊的命令作为队列，这是一个不错的选择。对于自托管服务器，我推荐Beanstalkd，它非常高效，占地面积小，并且包含在许多操作系统的包管理器中。奇怪的是，SQS是否可能因为远程且位于不同的服务器上而比DB慢？或者都是远程的，或者都是本地的？