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