关于何时使用JMS（或一般队列）与数据库的混淆 [英] Confused as to when you would use JMS (or a queue in general) versus a database
问题描述
当您将消息存储在队列中时，是不是更多的元数据信息，那么从队列中提取的人知道如何处理数据？队列中的实际信息并不总是包含所有信息。
When you store a message in a queue, isn't it more of meta data information so whoever pulls from the queue knows how to process the data? the actual information in the queue doesn't always hold all the information.
假设您有一个类似Twitter的应用程序，每当有人发布消息时，您仍然需要存储数据库中的实际消息文本是否正确？
Say you have an app like Twitter, whenever someone posts a message, you would still need to store the actual message text in the database correct?
队列将更多地用于向其他订阅者广播新消息已到达，然后这些服务可以采取进一步行动。
The queue would be more used to broadcast to other subscribers that a new message has arrived, and then those services could take further action.
或者你真的可以将推文文本存储在队列中吗？ （或者你可以，但那会很愚蠢吗？）
Or could you actually store the tweet text in the queue also? (or you COULD, but that would be silly?)
队列消息是否有状态字段，哪些订阅者可以在处理部分工作流时更改？ （或者你会在数据库中执行此操作吗？）
Could a queue message have status fields, which subscribers can change as they process their part of the work flow? (or would you do that in the db?)
只是想弄清楚何时使用队列而不是数据库。
Just trying to get some clarification of when you would use a queue versus db.
推荐答案
当进程想要将数据和数据处理到另一个进程（可能在不同的主机上）时，那里有两种策略：
When a process wants to farm data and the processing of that data out to another process (possibly on a different host), there are 2 strategies:
-
将所有数据存入队列项目，让接收应用程序担心将其存储在数据库中，其中包括其他任何处理。
Stuff all your data into the queue item and let the receiving app worry about storing it in the database, among with whatever other processing.
更新您的数据库，然后将一条小消息排队到另一个进程，只是为了通知它有新的数据需要按摩。
Update your database, and then queue a tiny message to the other process just to notify it that there's new data to be massaged.
可以使用多种因素来决定采用哪种策略：
There are a number of factors that can be used to decide on which strategy:
-
如果您的数据库完全是ACID（人们希望），但您的排队系统（QS）不是，那么您的数据在数据库中会更安全。即使队列消息在服务器崩溃中丢失，您也可以运行脚本来处理在数据库中找到的未处理数据。这是选项2的情况。
If your database is fully ACID (one would hope) but your queueing system (QS) is not, your data would be safer in the DB. Even if the queue message gets lost in a server crash, you could run a script to process unprocessed data found in the DB. This would be a case for option 2.
如果您的数据非常大（例如，1 MB或更多），那么QS的负担可能会很残忍用它。如果它是持久的，你最终会将数据写入两次，首先是QS的持久性，然后是数据库。这可能会拖累性能并影响您选择1。
If your data is quite large (say, 1 MB or more) then it might be cruel to burden your QS with it. If it's persistent, you'll end up writing the data twice, first to the QS's persister and later to the DB. This could be a drag on performance and influence you to go for option 1.
如果您的数据库速度很慢或甚至无法访问应用程序的前端，那么选项1是。
If your DB is slow or not even accessible to your app's front end, then option 1 it is.
如果您的第二个流程要对数据执行某些操作但不将其存储在数据库中，那么选项1可能就是这样去吧。
If your second process is going to do something with the data but not store it in a DB, then option 1 may be the way to go.
再也想不到了，但我希望你明白这一点。
Can't think of any more, but I hope you get the idea.
这篇关于关于何时使用JMS（或一般队列）与数据库的混淆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
