併發消費者尚未確保訂單

我有一個以非常高的速率（> 100,000 /秒）填充的JMS隊列。併發消費者尚未確保訂單

可能發生的情況是，每秒鐘可能有多個屬於同一個實體的消息。（實體的幾次更新，每次更新都作爲不同的消息。）

另一方面，我有一個消費者處理此消息並將其發送給其他應用程序。

現在，整個設置正在放緩，因爲消費者無法應付收到的消息的速度。

因爲消費者處理消息的速度有SLA，所以我一直在玩弄讓多個消費者並行工作來加速流程的想法。

那麼，是什麼即時通訊思想做的是

隊列獨立工作的多個消費者。
每個消費者可以自由地抓住任何消息。
抓取消息後，確保其實體的最新版本。爲此，我可以檢查處理這個實體的應用程序。
如果它不是最新版本，請將版本提升並重試。

我一直在查找集成模式，JMS文檔到目前爲止沒有成功。

我希望能夠以更優雅的方式解決這個問題，以及任何已知的API，Java世界中的模式。

來源

2012-07-19 Anand Hemmige

Apache Camel應該能夠做到這一點。 http://camel.apache.org/parallel-processing-and-ordering.html – 2012-07-19 19:45:31

謝謝。這個鏈接提供了我對這個問題的不同考慮。我將在此基礎上進一步研究。 – 2012-07-19 19:51:12

讓我知道這是否有效。如果有效，我會發表評論作爲答案，以便您可以接受。 – 2012-07-25 13:49:22

大多數EIP框架和ESB都有可定製的重排序器。如果實體數量不是很大，則可以爲每個實體設置一個隊列，並在開始時重新排序。

來源

2012-12-31 18:56:53 iwein

ActiveMQ用a concept called "Message Groups"解決了這個問題。雖然它不是JMS標準的一部分，但是它是several JMS-related products work similarly。其基本思想是將每條消息分配給一個「組」，該組指出了相關的消息並且必須按順序處理。然後，您將其設置爲每個組僅交付給一位消費者。因此，您可以在組之間獲得負載平衡，但可以保證組內的按序交付。

來源

2012-12-31 19:42:13

爲有興趣的方式來解決這個問題的那些：

使用Recipient List EAI模式

由於問題是關於JMS，大家可以看到從Apache Camel website一個例子。

此方法與CBR和Selective Consumer等其他模式不同，因爲消費者不知道應該處理什麼消息。讓我把它放在一個現實世界的例子：

我們有一個訂單管理系統（OMS）發送訂單由ERP處理。然後，訂單經過6個步驟，每個步驟都在Order_queue上發佈一個事件，通知新訂單的狀態。沒什麼特別的。 OMS消耗來自該隊列的事件，但是必須按照它們發佈的順序處理每個訂單的事件。每分鐘發佈的消息速率遠遠大於消費者的吞吐量，因此延遲會隨着時間的推移而增加。

將溶液的要求：

消耗並聯，以維持隊列大小在合理的量包括作爲許多消費者。
保證每個訂單的事件在相同的發佈訂單中處理。

實施：

在OMS上側 的OMS過程負責發送訂單到ERP，決定了消費者將處理一定順序的所有事件，並將隨着收件人姓名命令。這個過程如何知道接收者應該是什麼？那麼，你可以使用不同的方法，但我們使用了一個非常簡單的方法：Round Robin。

在ERP 由於它保留每個訂單的收件人姓名，它只需設置要傳遞給所需收件人的郵件。

On OMS Consumer 我們部署了4個實例，每個實例使用不同的收件人名稱並同時處理消息。

有人可以說我們製造了另一個瓶頸：數據庫。但事實並非如此，因爲訂單行沒有併發性。

一個缺點是發送訂單到ERP的OMS過程必須保持關於有多少收件人正在工作的知識。

來源

2014-07-31 15:00:49 Alexander

併發消費者尚未確保訂單

回答

相關問題