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

Laravel Queue, Beanstalkd vs Database, what are the differences?

提问by Nicekiwi

Is there much difference between using Beanstalkd and a database driver for queues?

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

What would some pros and cons be? The database queue seems to easier to setup and run, what should I know about using it?

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

Theres no real explanations in the docs about it.

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

回答by Arpit

Using a database as a queue can be simpler to setup and probably easier to test on a development machine. But running a database as a queue in production may not be a very good idea; especially in a high traffic scenario. Although a database may not be the right tool for queueing, let's look at the pros & cons of using it as such.

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

Pros:

优点：

• Easier to setup
• May reduce the number of moving parts in your application if you use the same database

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

Cons:

缺点：

• For lot's of reads and writes, there has to be some mechanism for locking rows and updating the indexes etc.
• Polling workers would also lock up an index in order to do work on it and update the row with the final status of the job.
• In such scenarios, the writes to the DB may be queued and would take longer to execute.

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

Messaging queues such as SQS, Beanstalkd, RabbitMQ etc. are built to handle these scenarios. Since they only care about a message being stored and processed, they don't have to worry about locking and transaction logging (which is required by a database). Adding a messaging queue to your system will help it scale much more easily. Also, it'll let the database breathe by allowing it to do actual transaction processing without worrying about messaging as well.

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

回答by Artur Grigio

I did some testing on one of my production servers.

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

The scenario: Insert a new visitor tracking info (ip, city, state, country, lat, lng, user-agent, etc)(To insert a new entry, you need to make sure the IPhasn't had a visit in the last 24 hours), so it also has a selectquery.

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

(note: table size is in millions, and the instance is micro, just to see what the worst case is)

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

Here are the numbers I got:

这是我得到的数字：

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

1. Obviously, syncis the worst option, as the user has to sit there for 2.3 seconds, before he even starts receiving any data.
2. databasehas the best results, but as mentioned earlier, might not be the best solution for high visitor numbers. Additionally, you shouldn't forget that there is still an insertbeing made into the jobstable.
3. AWS SQSto my surprise was slower than using the database. I'm guessing it's because with databaseyou already have established connections to the database in your connection pool, but the SQShas to establish a TLSconnection every time. Hence, the additional 300-400ms.

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

I honestly don't think that SQSwas hard to setup (just follow the guide). I think the decision is based on what your visitor number is.

老实说，我认为这SQS并不难设置（只需按照指南进行操作）。我认为该决定取决于您的访客编号。