LMAX Disruptor如何解決典型的消息代理問題？

我的瞭解LMAX Disruptor的是它是一個JAR，它充滿了令人恐怖的，可怕的併發Java代碼，每秒鐘吞吐量達到2000萬條消息（如果使用正確的話）。LMAX Disruptor如何解決典型的消息代理問題？

我們目前有一個ActiveMQ實例，對於我們需要它的整個實例來說，速度很慢，大約爲每秒400條消息。我想知道，如果我們從重構我們的代碼使用LMAX受益，但有以下擔憂：

如何有1個出版商和多個（競爭）消費者
如何LMAX店/房子它的消息？在記憶中？
故障轉移 - LMAX是否具有故障轉移協議/機制
磁盤I/O - LMAX是否可以將未使用的消息保存到磁盤並在稍後恢復它們？

而且，如果我與所有這些完全關閉基地，並且似乎是完全誤解了使用LMAX干擾物，然後有人可以提供時，將使用它的一個具體的例子嗎？提前致謝！

2013-03-29 IAmYourFaja

Disruptor不是直接替代跨進程或跨服務器消息傳遞系統。它被設計爲一個內部進程的跨線程消息傳遞系統。把它看作是有用的，可以替換通常在它們之間有隊列的處理線程之間的依賴關係圖。這對於在線程之間使用流水線或多播模式的設計非常有用。 ActiveMQ服務於不同的目的。

基於Disruptor的系統中的線程更像是通過經由Disruptor傳遞事件進行通信的長壽命Actor。

有關一些很好的示例，請參閱源代碼中提供的性能測試。

來源

2013-03-30 13:21:40

Thanks @Martin Thompson（+1）。那麼讓每個線程像其自己的企業集成模式（EIP）一樣行動的想法，以及Disruptor是每個EIP線程之間的超快速消息傳遞系統？ – 2013-03-30 15:16:14

Disruptor對於將IO放在網絡或磁盤前面很有用，因此可以應用智能批處理，因此可以以無鎖方式分攤昂貴IO操作的成本。我不是大多數「企業」軟件的粉絲，因爲它可以增加很少的代價。單獨的線程可以處理IO，但它們也可以執行業務邏輯。邁克和我幾年前在QCon上談論過這件事。 http://www.infoq.com/presentations/LMAX –

LMAX Disruptor如何解決典型的消息代理問題？

回答

相關問題