有狀態服務器的故障轉移策略

Question

在我們的項目中，我們有一個有狀態的服務器。服務器運行規則引擎（Drools）並使用休息服務公開功能。它是監控系統，正常運行時間或更少100％是非常關鍵的。因此，我們還需要策略來關閉服務器進行維護，並制定策略以便在一臺服務器脫機時能夠繼續監視代理。

第一個可能是在drools服務器前放置消息隊列或服務總線，以保留尚未處理的消息並具有將服務器狀態備份到數據庫或其他存儲的機制。這使得關閉服務器幾分鐘來部署新版本成爲可能。但問題是，當一臺服務器意外脫機時該怎麼辦。有狀態服務器是否有任何故障切換​​策略，您有什麼經驗？歡迎提供建議。

Answer 1

我沒有想到的「正確」方式。它取決於如下幾點：

1. 對時間窗口變化的敏感度。
2. 您的應用程序需要多快才能恢復。
3. 如果事件被錯過，會產生影響。
4. 如果它正在監測的事件沒有達到第二個，則會受到影響。
5. 應用程序如何將事件引發回外界。

的一些想法實現故障切換：從

洗涮

1. 開始。在花費時間開發其他任何東西之前，檢查這個最嚴重的影響。
2. 從數據庫中加載事實列表（可能是今天的事務）。按順序重播。可能同時使用僞時鐘。我知道這被用於金融領域的一些定價應用，但同時我也意識到，由於需要的事件數量很多，這些系統中的一些可能需要很長時間才能趕上重播。
3. 定期保持有狀態會話。基於允許DR應用程序落後多長時間來確定時間間隔，以及持續會話需要多長時間。這樣，DR應用程序就可以從數據庫中檢索相同的會話。但是，根據持續時間間隔收到的事件會有差距。當然，如果失敗的原因是會話的腐敗，那麼這個效果並不好。
4. 配置中間件將事件轉發到2個隊列，並將主應用程序和DR應用程序訂閱到這些隊列。這樣，兩臺顯示器應該同步並且能夠根據最後1分鐘的活動做出決定。請注意，如果一條支線被取出一段時間，那麼它將需要趕上，並且您的中間件需要有能力存儲隊列中多個小時（可能長時間停運）的值。此外，您的規則需要在排隊時排除事件本身的時間戳，而不是當前時間。否則，在停電後恢復原狀時，可能會根據時間窗口中的事件發出警報。

重放事件時需要考慮的另一點是，您可能不希望在完成重播之前向外界提示任何警報。例如，您可能不希望發送50封警報電子郵件來說明ApplicationX處於關閉，上下，上，下，上......

我假定監控應用程序可能以某種形式向外界推送警報。如果您擁有4中的熱點配置，則還需要控制警報。我會試圖通過配置每個將警報推送到它自己的隊列來解決這個問題。然後，中間件可以將來自輔助監視器的警報轉發給死信隊列。故障轉移將重新配置中間件，以便主要警報進入死信隊列，二級警報進入警報通道。該機制也可用於丟棄重放恢復期間引發的事件。

考慮到重放事件可能導致的複雜性和潛在的混亂，對於監控應用程序，我可能更喜歡從乾淨的版本開始，或者使用持久會話。但是，這可能很大程度上取決於您正在監視的內容