對於我們的下一代產品之一，我一直要求設計同時具有故障切換功能的系統（即有幾個節點，如果其中一個節點崩潰有最小/無數據丟失）和負載均衡（所以每個節點只處理部分數據）。我無法相信的是我如何能夠做到這一點。假設一個節點擁有所有的數據，但只處理一個約定的子集。比如，它會改變元素8。現在所有其他節點都有錯誤的元素8.所以我需要同步 - 告訴所有其他節點元素8改變 - 以保持完整性。但肯定這只是對負載平衡的嘲弄？！故障轉移和負載平衡 - 互斥？
簡短的回答是，它在很大程度上取決於你的應用程序體系結構。
這聽起來像您使用的是糟糕的設計反模式思考這個 - 試圖在同一層同一時間向外擴展處理和災難恢復解決。如果每個節點只處理部分數據，那麼它不能成爲其他節點的故障轉移。很多人陷入了這個陷阱，因爲擴大規模和DR都可以使用一種聯邦來實現......但是不要混淆機制和目標。我會恭敬地提交你需要以不同的方式思考這個問題。
解決這個問題的方法是在兩個完全分離的層：
1層 - 應用程序。爲您的應用程序設計一個高級設計，就好像沒有DR需求一樣。忽略其他地方可能會有另一個此應用的實例在DR中使用。關注應用程序的功能&性能方面 - 不同的子系統應該是什麼，如果有任何應該擴展出於工作負載的原因。這個應用程序作爲一個整體處理100％的數據 - 決定應用程序本身是否需要擴展/聯合方法 - 這與DR需求無關。
二層技術 - DR。現在將您的應用視爲黑盒子。您需要多少個黑匣子實例來滿足您的可用性要求，以及您將如何保持這些實例之間所需的同步程度？什麼是故障轉移&恢復性能要求（時間如有可用性，可允許的數據丟失，則需要在未來的故障轉移ENV了&跑了多久）？
回到1層 - 選擇適合您的高層次的設計，使用您在第2層識別例如回收的方法和工具，如果你將使用中的數據同步的主從DB方法的實施辦法DR節點，將您希望保留的所有內容存儲在數據庫層的故障轉移中，而不是存儲在應用程序節點本地文件或內存中。這些選擇取決於您選擇的DR框架。
應用層和DR層的設計是相關的，但如果您選擇正確的工具方法，則不必強烈耦合。例如。在Amazon Web Services中，您可以使用IP負載平衡將請求轉發到故障轉移應用程序實例，並且如果您將所有相關數據（包括會話和其他瞬態事物）存儲在數據庫中，並使用DBMS本機複製功能，則非常簡單。
底線：
祝你好運