2016-10-06 7 views
0

Ich habe WSO2ESB Cluster (ESB1 und ESB2 Arbeiter) und ich konfiguriere WSO2MB Cluster mit freigegebenen Datenbank MSSQL (MB1 und MB2 Broker). ESB-Server schreiben und lesen Nachrichten von den Brokern im WSO2MB-Cluster. Was ich erreichen möchte, ist, dass ESB1 lesen/schreiben Nachrichten an Broker MB1 und ESB2 wird lesen/schreiben Nachrichten an Broker MB2. Bei Ausfall von zB MB2 lesen/schreiben beide ESB-Server Nachrichten in MB1. In der Dokumentation sehe ich nur eine Round-Robin-Version der Fehlerstrategie, das heißt, dass ESB-Server zufällig eine Verbindung zu MB-Brokern herstellen. Es gibt Single-Broker-Strategie, aber ist das in meiner Situation anwendbar oder muss ich meine eigene FailoverMethod-Schnittstelle implementieren? Ich brauche eine Prioritäts- oder Gewichtungs-Failover-Strategie, und ich sehe das nur in ActiveMQ. Thnx für jede Antwort.WSO2 ESB zu Message Broker-Failover

Antwort

0

Round-Robin ist kein zufälliger Algorithmus, der mit Brokern verbunden ist. Es priorisiert Broker in der angegebenen Reihenfolge in broker list von der ersten bis zur letzten. Mit den konfigurierbaren "Cycle Count" -, "Retries" - und "Connection Delay" -Eigenschaften können Sie auch die Wiederholungsversuche auf Broker mit niedriger Priorität minimieren. Obwohl wso2 mb im Moment keine gewichtete Failover-Strategie hat, können Sie versuchen, ein ähnliches Verhalten durch obige Konfigurationen zu erreichen.

Soweit ich in 2 Knoten Broker-Cluster (in Ihrem Anwendungsfall) verstehen, ist die Priorisierung eines Brokers (gewichtete Failover-Strategie) kein gültiger Fall. Wenn beispielsweise MB1 inaktiv ist, ist nur die Option für Failover MB2 und umgekehrt verfügbar. Wenn Sie ESB1 nicht mit MB2 verbinden möchten (während MB1 nicht verfügbar ist), entfernen Sie einfach die Verbindungs-URL von MB2 aus der Brokerliste in der Datei "jndi.properties" von ESB1. Darüber hinaus müssen Sie "Anzahl der Zyklen", "Wiederholungen", "Verbindungsverzögerung" in MB1-Broker-URL variieren, um einen erneuten Versuch zu versuchen, bis MB1 wieder verfügbar ist. Daher kann dieser Anwendungsfall leicht durch eine Round-Robin-Strategie erreicht werden.

+0

Ja, wir analysierten den Quellcode der Failover-Schnittstelle und es funktioniert wie Sie erwähnt haben. Die einzige Frage ist jetzt - wenn MB1 wieder zum Leben erwacht, schaltet das Failover nach einiger Zeit auf es um? Mit anderen Worten, die Verbindung wird nach jeder Transaktion zurückgesetzt und überprüft die Liste der Broker erneut? In meinem Beispiel ist MB1 nicht aktiv, so dass die Round-Robin-Strategie auf MB2 umschaltet und nachdem MB1 wieder hochgefahren ist, brauchen wir ESB1, um wieder damit zu arbeiten. –