並發消息處理設計爭議

Question

最近，我設計了一個系統，該系統使用Oracle Advanced Queuing（AQ）使用JMS處理運行狀況數據。 該消息必須包含患者信息，例如姓名，健康卡號等。此外，該消息還可能包含患者免疫記錄。 我正在使用Spring Boot，通過配置多個消息偵聽器（最多30個），我能夠同時處理這些消息。 這樣我就能獲得表現。 但是，這些消息未按時間順序進行處理，從而導致數據不一致。 例如，消息A代表新的患者記錄，消息B代表對使用消息A創建的患者的更新。如果隨后進行處理（消息A，然后消息B），則結果與上游系統一致。 但是，如果同時處理，結果將與現實不同步（消息B可能在消息A之前得到處理）。 顯然，如果有消息A，我將不會開始處理消息B。假設我有確定消息的手段（每條消息都有事件時間戳和狀態）。 但是如何實際實施呢？ 如果有人分享他們的經驗，我將不勝感激。 實際技術沒關系，我正在尋找某種設計模式

Answer 1

如果您想堅持使用JMS作為技術，並且不能使用消息分組，那么我會看到兩種基本的處理方法。

序列化所有消息處理

通過序列化所有消息處理，您將確保不對任何消息進行亂序處理。 但是，這可能會導致性能顯着下降。

重試亂序消息

當您發現要亂序處理一條消息時，您可以簡單地回滾該消息的使用情況並配置重新交付延遲（假設最終將在當前消息“超前”之內處理該消息）延遲時間。 大多數JMS代理有時甚至在重新交付延遲越來越長的情況下，都支持同一條消息的多次重新交付，並且最終還具有在一定數量的交付嘗試之后將無法交付的消息放入某種“死信”隊列中的能力。 這樣做的好處是，您可以繼續並發處理消息（具有並發性所帶來的所有性能優勢），並且只需要在訂單實際中斷時處理亂序消息即可。 不利的一面是，您可能會浪費一些時間多次重復處理某些相同的消息，並且您將需要建立某種過程來處理最終被認為無法傳遞的消息（盡管您可能仍然必須這樣做）。

Answer 2

在不犧牲順序的情況下獲得性能的一種方法是將數據分布在多個不重疊的主題中 。 因此，患者A和患者B可以涉及不同的主題，但是對患者A的更新將僅涉及患者A的主題。

怎么樣 ？ 一種開始的方法是使用患者的姓氏的首字母作為主題。 因此，所有耐心的Miller消息都在主題M上，而John Doe的話題在D上。當然，這種分布並不理想（對訂戶'X'來說工作量不大），但是您也可以使用全名模的哈希碼例如30。 或者，如果您有ID，請使用ID的后兩位數字發布和訂閱主題00到99。

如果您擔心丟失消息，請使用JMS持久訂閱或設置X個隊列。

Answer 3

只是為了結束討論。 我的最終決定是@Justin Bertram所建議的，只需使用延遲選項將消息發送回隊列即可。 Oracle Advance Queuing允許使用延遲選項對消息進行排隊。