非常長的駱駝relivery政策

Question

我正在使用駱駝，我有一個業務問題。我們使用來自activemq隊列的訂單消息。我們要做的第一件事是檢查我們的數據庫，看看客戶是否存在。如果客戶不存在，則支持團隊需要在不同的系統中填充客戶。有時這可能需要10小時甚至第二天。

我的問題是如何處理這個問題。在我看來，在高層我可以將這些消息出列，將它們存儲在我們的數據庫中並且間隔地重新運行它們（自定義編碼的解決方案），或者我可以在我們的數據庫中記錄錯誤，然後將它們返回到activemq隊列長期的重新交付政策和到期時間表示，每2小時重新交付48小時。

這會節省很多代碼，但我的問題是如果方法2是一種合理的方法，或者可能導致資源問題或不知道消息在哪裏的問題？

Answer 1

這是一個很常見的情況。如果您想深入瞭解工作進展情況，那麼最好使用數據庫。

您的隊列消耗應該非常簡單：消費消息，檢查客戶是否存在;如果是這樣的話，否則在TODO表中寫一條記錄。

設置一個單獨的路線在定時器上運行 - 每X分鐘。它應該提取TODO記錄，並且對於每個記錄檢查客戶是否存在;如果是這樣的話，否則用當前時間戳（上一次重試記錄）更新記錄。

這使您可以清楚地瞭解系統的狀態，然後可以將其集成到控制檯中，以查看未完成作業的狀態。

有幾個缺點與您的選項2：

• 你依靠ActiveMQ的調度，它採用了KahaDB變種坐在你旁邊正規商店，並不得與您的H兼容/一個設置（你需要一個共享文件系統）
• 你不能在沒有掃描隊列的情況下看到消息，這是一個反模式 - 使用隊列作爲數據庫 - 你也可以使用數據庫，特別是如果你可以預見需要有選擇地刪除特定的消息。