Terracotta是否使JMS成為不需要的層？

Question

我們目前正在編寫一個IT已經為其購買硬件的應用程序。 他們的方法是購買我們將部署的大型硬件。 為了增加更多處理，他們計划添加具有相同軟件的其他服務器。 為了適應這種設計，我們使用Terracotta來提供運行多個JVM的能力，就像它是一個大型JVM一樣。 無論這是否是一種明智的方式（我仍然不相信），這就是我正在處理的情況。

無論如何，我們有一部分應用程序使用標准的生產者/消費者類型隊列。 使用Terracotta，我們可以創建一個可與多個JVM一起使用的單個隊列。 這很漂亮，效果很好。

但現在，我們正在尋找額外的機會來運行異步流程。 為了使我們的所有排隊邏輯更加一致，我們正在考慮使用JMS來抽象出通用邏輯。 由於我們不打算將JMS用作遠程隊列（至少在可預見的未來），我想知道JMS是否只是增加了不必要的復雜性。

有什么建議或想法？ 我們應該繼續將隊列構建為並發結構，還是將它們視為單獨的可能遠程對象？

Answer 1

消息隊列本質上只是具有一些奇特選項的隊列數據結構。 如果您的項目與大多數其他項目一樣，那么您不會使用任何使JMS與任何舊Queue實現不同的JMS功能，尤其是因為Terracotta正在處理持久性和分發。

所以JMS可能只是增加了應用程序的復雜性，這是JMS非常擅長的。 像所有不需要的復雜驅動程序一樣，擺脫它。 如果您出於一個或多個原因決定使用JMS，那么請執行此操作。

Answer 2

我的一位同事一直在使用Mule ，它允許您定義可能是JVM內部或JVM間隊列的隊列。

我同意krosenwald ：目前尚不清楚JMS會在你的情況下添加什么，除非有一個總體計划要么離開兵馬俑（或者至少可以選擇）。

Answer 3

我沒有使用過Terracotta，但我們使用的是與它非常相似的分布式緩存產品。 我們的架構聽起來與您的架構相似。 生產者和消費者都坐在同一個緩存中並使用緩存子系統共享數據。

雖然我同意校長認為現在添加JMS對您來說可能是一種不必要的復雜性，但我們發現，雖然光滑，但分布式緩存並不是消息傳遞機制的最佳實現。 雖然可以創建相同的sematics，但是一些小的細節會導致問題（例如，消費者的負載平衡，這可能需要與分布式緩存進行額外的同步，但是與JMS自然地協同工作。）

如果您認為未來的用例需要更多pub-sub語義和持久性等，那么您可能需要開始考慮JMS。 另外，考慮分離關注點。 您正在使用Terracotta來分發數據（這是它的目的）。 您是否也會使用它來分發控制指令（這可以通過消息語義更好地完成）？