2011-03-02 48 views
4

在我們的體系結構中,即使與本地網絡的連接丟失,JMS發佈服務器也可能繼續工作(並生成新消息)。是否有可能使發行者服務器容忍網絡或經紀人中斷與JMS:JMS容錯異步發佈服務器

  1. 發佈調用可能不會阻止應用程序,即使代理不可用;
  2. 發佈的消息(停電期間)必須在網絡連接恢復後交付;

據我瞭解,可以在每臺出版機上使用嵌入式(本地)代理。如果這是唯一的方法,那麼拓撲中是否存在任何非顯而易見的問題 - 性能,維護等?本地經紀人是否可以忍受中斷?

回答

2

我還沒有試過,但好像你可以使用本地故障切換,以減少阻抗: 和ActiveMQ,您可以配置故障轉移運輸:

failover:(tcp://primary:61616,tcp://secondary:61616)?randomize=false 

要嘗試並得出這樣的:

client +---> primary: network broker <-------+ 
     |          | 
     +---> secondary: embedded broker -----+ 

這裏的主要是你的網絡經紀人,你的第二經紀人將是本地嵌入的經紀人,並與主經紀人建立橋樑。這看起來似乎在客戶發佈配額時會起作用;我不知道這是否會成爲訂閱然後通過@Biju提出的解決方案更好:如下圖所示:

client +---> secondary: embedded broker ------> primary: network broker 

例如這裏是我的嵌入式代理(通常是不可持久)。

<bean id="activeMQBroker" class="org.apache.activemq.broker.BrokerService"> 
    <property name="transportConnectors"> 
     <list> 
       <bean id="brokerConnection" class="org.apache.activemq.broker.TransportConnector"> 
        <property name="connectUri"> 
         <bean id="brokerURI" class="java.net.URI"> 
          <constructor-arg value="tcp://localhost:61616" /> 
         </bean> 
        </property> 
       </bean> 
     </list> 
    </property> 

    <property name="persistent" value="true" /> 
</bean> 
+0

好吧,但我怎麼做第二個經紀人本身容忍連接損失?經紀人之間的什麼類型的連接應該是防止第二人在網絡連接恢復後死亡,掛起和保證消息傳遞? – Shcheklein 2011-03-02 16:48:06

+1

嵌入式代理通常有一個文件存儲區,用於將傳入消息寫入。橋應該容忍連接丟失(從我記憶中)。請參閱http://activemq.apache.org/jms-to-jms-bridge.html。 – Justin 2011-03-02 16:55:24

+0

帶故障轉移傳輸的嵌入式代理至今仍在運行。但是,Active MQ中存在一個錯誤,它可以防止在訂戶進程中使用嵌入式代理:[AMQ-3213](http://issues.apache.org/jira/browse/AMQ-3213)。有時,即使使用一個嵌入式代理(發佈者)和一個遠程代理也會發生同樣的問題。解決方案似乎是正確的,AMQ似乎是越野車。 – Shcheklein 2011-04-12 15:39:53

0

,我能想到的唯一的辦法是沿着你所建議的線 -

  1. 具有本地嵌入式代理,並從該嵌入式代理到基於網絡的經紀人提供了一個橋樑。即使是當地的一個雖然可以往下走,所以你可以有你的資源之間的事務發佈(DB和JMS基礎設施)
  2. 不要直接發佈,而是有其緩衝它的抽象 - 到數據庫,文件,或像上面到一個本地嵌入式jms,並從緩衝區向JMS隊列提供如上所示的橋接。
+0

我想,如果嵌入式代理出現故障,可以考慮像致命錯誤出版商,如果數據庫層是這樣下來 – Shcheklein 2011-03-02 14:00:03

+0

「的抽象,它緩衝... 「 - 完全!但我希望能夠提供這種功能。爲什麼我需要JMS,如果我不得不爲其編寫額外的緩衝和持久層? – Shcheklein 2011-03-02 14:03:22

+0

@Shcheklein,真的,如果消息源(數據庫說)和目的地(jms隊列)可以被拉入到一個公共事務(XA) – 2011-03-02 14:45:50

0

分佈式體系結構,如果隊列管理器\ broker在您描述的情況下非常常見。

的確切配置取決於您使用的具體產品,但它通常是有據可查的,易於管理

關於本地冗餘,可以使用兩個這樣的隊列管理器的容錯配置(再次 - 確切的方法創建容錯集羣依賴於產品) - 但這看起來有些過度。

JMS規範只有消息隊列提供的API,其他

+0

這是JMS「規範」中最令人沮喪的方面(安全性也沒有定義)。您可以編寫完美的可移植JMS代碼,但不能部署即可使用。 – Justin 2011-03-03 01:35:27