故障转移和负载平衡 - 互斥？
对于我们的下一代产品之一，我一直要求设计同时具有故障切换功能的系统（即有几个节点，如果其中一个节点崩溃有最小/无数据丢失）和负载均衡（所以每个节点只处理部分数据）。我无法相信的是我如何能够做到这一点。假设一个节点拥有所有的数据，但只处理一个约定的子集。比如，它会改变元素8。现在所有其他节点都有错误的元素8.所以我需要同步 - 告诉所有其他节点元素8改变 - 以保持完整性。但肯定这只是对负载平衡的嘲弄？！故障转移和负载平衡 - 互斥？
简短的回答是，它在很大程度上取决于你的应用程序体系结构。
这听起来像您使用的是糟糕的设计反模式思考这个 - 试图在同一层同一时间向外扩展处理和灾难恢复解决。如果每个节点只处理部分数据，那么它不能成为其他节点的故障转移。很多人陷入了这个陷阱，因为扩大规模和DR都可以使用一种联邦来实现......但是不要混淆机制和目标。我会恭敬地提交你需要以不同的方式思考这个问题。
解决这个问题的方法是在两个完全分离的层：
1层 - 应用程序。为您的应用程序设计一个高级设计，就好像没有DR需求一样。忽略其他地方可能会有另一个此应用的实例在DR中使用。关注应用程序的功能&性能方面 - 不同的子系统应该是什么，如果有任何应该扩展出于工作负载的原因。这个应用程序作为一个整体处理100％的数据 - 决定应用程序本身是否需要扩展/联合方法 - 这与DR需求无关。
二层技术 - DR。现在将您的应用视为黑盒子。您需要多少个黑匣子实例来满足您的可用性要求，以及您将如何保持这些实例之间所需的同步程度？什么是故障转移&恢复性能要求（时间如有可用性，可允许的数据丢失，则需要在未来的故障转移ENV了&跑了多久）？
回到1层 - 选择适合您的高层次的设计，使用您在第2层识别例如回收的方法和工具，如果你将使用中的数据同步的主从DB方法的实施办法DR节点，将您希望保留的所有内容存储在数据库层的故障转移中，而不是存储在应用程序节点本地文件或内存中。这些选择取决于您选择的DR框架。
应用层和DR层的设计是相关的，但如果您选择正确的工具方法，则不必强烈耦合。例如。在Amazon Web Services中，您可以使用IP负载平衡将请求转发到故障转移应用程序实例，并且如果您将所有相关数据（包括会话和其他瞬态事物）存储在数据库中，并使用DBMS本机复制功能，则非常简单。
底线：
- 不要混淆DR节点性能的横向扩展节点（应用程序内部）（整个应用程序）
- 使用灾难恢复方法的选择，以推动应用程序实现决策层
祝你好运