我們有一個很大的項目即將推出，其中很多媒體處理（圖像，視頻）以及電子郵件輸出等，通常我們會把這些東西放到一個叫做「email_queue」，我們使用cron來運行腳本處理表中的隊列。消息隊列與數據庫表隊列通過CRON
我一直在閱讀很多Message Queue系統，比如beanstalkd，甚至已經設置了它。使用起來很簡單而且很好用，問題是我不確定我是否缺少一些東西。
有人可以詳細說明使用隊列系統而不是表和CRON的好處嗎？因爲我真的看不到他們是什麼。
由於
消息隊列（至少一個分佈式之一，例如RabbitMQ）給出您跨物理節點分發工作的能力。您仍然需要在每個節點上擁有一個進程，以使工作出列和處理。
它最終得到您的要求，我猜。您可以使用消息隊列大規模地實現更易於管理的解決方案：您可以更輕鬆地解耦您的節點。
當然，有一條學習曲線......所以它再次回到你的目標。
注意，每個節點上你仍然可以重用的cron/db表，直到（如果）你想改變的執行情況。 當你可以時，這就是解耦的好方法。
差異：
一旦消息被放在可以立即傳送隊列中。因此，如果您的cron通常每5分鐘運行一次，您可以通過排隊更快地處理。
如果您的排隊系統支持交易，那麼如果處理失敗，它將自動重新發送消息。
查詢隊列中的內容可能比較困難。數據庫表有很好的搜索方式（sql）。
如果您有多個處理消息的服務器/進程/線程，隊列系統將確保消息僅傳遞給其中一個消息。隨着數據庫的表，你需要通過應用程序代碼來處理這個（鎖定，標誌等）
偉大的觀點，在我看來更好的答案。 – 2013-03-26 18:03:42
首先，隊列往往是由實際的數據庫表支持，並能保持消息的耐用性。除此之外，隊列是推動需要異步完成的工作的一種自然方式，如果您從一開始就對該主體進行設計的話非常強大。
除了表（實體）具有一組硬盤（屬性）的事實以外，該表由一組記錄組成以及一個隊列組成，只不過是您正在使用的東西列表隊列作爲一個正式的隊列，只是你正在按常規（cron）輪詢它。
MQ通過一般同步對消息本身的訪問（您可能會或可能不會在您的SQL中執行此操作來獲取下一個內容）來添加另一個漂亮功能。
我喜歡將cron/table機制視爲基於POLL的，而將MQ視爲基於EVENT的機制。
好處在我看來是一個隊列，它負責同步，狀態更新。 MQ可以設置爲「廣播」（主題）或將消息提供給一組消費者或聽衆。
儘管異步MQ可能會在您的cron窗口之間運行。您如何知道在您的表中處理的消息數量可以在下一個cron作業運行之前完成並嘗試執行之前的作業？
MQ的多個消費者允許您根據需要調整工作。在上面的示例中，如果您看到load average（與操作系統的進程隊列中的值相同）超出您的喜好，您可以配置其他使用者來處理所述負載，並根據指標的需求將其加載和離線。
MQ可以設置爲具有不同的操作參數，例如消息優先級和性能（某些隊列可以保留在內存中，其他隊列可以保留到磁盤）。
缺點是（如前所述）隊列有時可能很難查詢和獲取度量。我總是發現擁有數據庫後備存儲的MQ系統，這樣我就可以使用SQL監視隊列。
這會得到相當頻繁的詢問，而且如果您對數據庫感到滿意，通常不會有令人信服的理由。 Here's one example thread。
我的意思是，你可能想要避免學習曲線，除非你的數據需求包括特別高的數量，如果你是cron而不是一個具有計時器的進程，這是不太可能的（更不用說帶定時器的多進程）。
嗨，我有點理解，但不能用table/cron做同樣的事情，遠程連接數據庫並在另一臺機器上運行cron？ – Bowen 2009-12-03 15:37:37
你當然可以，但這似乎是一個更「耦合的解決方案」。採用消息隊列方法，對於節點實現而言，您更加脫鉤。這可能是一件好事。 – jldupont 2009-12-03 15:38:59
耦合使用它使用格式爲y的數據庫x，或者因爲它使用格式爲b的隊列a？很好的問題@bowen。 – graffic 2010-10-09 20:50:18