什么时候使用数据库作业队列是有意义的？
我正在devise一个内部公司网站，用户可以提交计算作业。 在我的devise中，一个重要的因素是将作业保留在队列中，直到完成，即使系统出现故障。
互联网似乎反对这个想法，因为它“不是真正的数据库的目的”，更适合像Redis这样的关键/价值存储（或者使用Redis的作业队列，比如Kue for Node.js）。 我认为，从这个意义上来说，这个devise的目的是不会像对待作业队列中那样对相当短暂的数据进行读/写操作而使数据库负担过重。 在我的使用情况下，虽然数据库使用会很低，似乎数据库提供的数据持久性是我在这里寻找的关键function。
在我的阅读中，我发现像Redis这样的一些关键/价值商店有一个持久的function，但它并不是真正的build立起来的，以确保在系统崩溃的情况下所有的数据都可以恢复。
我在这里错过了什么，或者这听起来正确吗？
在我的阅读中，我发现像Redis这样的一些关键/价值商店有一个持久的function，但它并不是真正的build立起来的，以确保所有数据在系统崩溃的情况下都能被恢复。
在Redis中，数据使用后台线程从内存持久化到磁盘。 实际上，系统closures不会损坏您的数据库，但问题是系统可能会在磁盘快照之前或快照过程中closures，并且会丢失上次成功快照后创build的所有数据。
如果你能确定你的Redis服务器能够运行99.9％的时间，这不是一个大问题，但无论如何，这个问题是存在的。
在一天结束的时候，我最好的build议是你应该使用正确的工具：一个通用的数据库，不pipe是NoSQL还是SQL，都不适用于工作排队。 使用现有的工具，它已经像RabbitMQ一样。