在创建高可用性应用程序时，最常利用哪些设计模式？[已关闭]

我假设你正在编写一个服务器类型的应用程序（让我们暂时离开Web应用程序 - 有一些很好的现成解决方案可以帮助那里，所以让我们看看“我有这个很棒的新型服务器，我已经写了”，但我希望它是HA问题）。

在服务器实现中，来自客户端的请求通常（以某种形式）转换为某种事件或命令类型模式，然后在一个或多个队列上执行。

因此，第一个问题 - 需要以一种在集群中生存的方式存储事件/命令（即，当新节点接管主节点时，它会查看需要执行并开始的下一个命令）。

让我们从单线程服务器 impl（最简单的 - 概念仍然适用于多线程，但它有自己的一组问题0。处理命令时，需要进行某种事务处理。

另一个问题是管理副作用，以及如何处理当前命令的失败？在可能的情况下，以交易方式处理副作用，以便它们全部或全部无。即。如果命令更改了状态变量，但在执行中途崩溃，则能够返回到“上一个”状态是很棒的。这允许新的主节点恢复崩溃的命令，只需重新运行该命令即可。一个好方法是将副作用分解为较小的任务，这些任务可以再次在任何节点上运行。即。存储主请求开始和结束任务，许多小任务处理每个任务只有一个副作用。

这也引入了其他问题，这些问题会影响您的设计。这些状态变量不一定是数据库更新。它们可以是共享状态（例如内部组件的有限状态机），也需要分布在集群中。因此，用于管理更改的模式使得主代码必须看到它所需的状态的一致版本，然后跨集群提交该状态。使用某种形式的不可变（至少从执行更新的主线程）数据存储是有用的。即。所有更新都是在新副本上有效地完成的，这些副本必须经过某种中介程序或外观，这些中介程序或外观仅在跨群集更新后使用更新来更新本地内存副本（或群集中数据一致性的最小成员数）。

其中一些问题也存在于主工作线程系统中。

还需要良好的错误管理，因为状态更新时可能出错的事情的数量会增加（因为您现在涉及网络）。

我经常使用状态模式。对于副作用，您希望发送请求/响应，并使用特定于对话的fsm来跟踪进度，而不是一行更新。

另一个问题是端点的表示。即。连接到主节点的客户端需要能够重新连接到新的主节点，然后监听结果？还是简单地取消所有待处理的结果并让客户端重新提交？如果您允许处理挂起的请求，则需要一种识别端点（客户端）的好方法（即查找中的某种客户端ID）。

还需要清理代码等（即不希望等待客户端重新连接的数据永远等待）。

使用大量队列。因此，很多人会使用一些消息总线（jms表示java）以事务方式推送事件。

Terracotta（再次用于java）为您解决了很多问题 - 只需更新内存 - Terracotta是您在这里的门面/中介。他们只是为您的注入了各个方面。

Terracotta（我不为他们工作） - 引入了“超级静态”的概念，所以你得到了这些很酷的集群宽的单例，但你只需要知道这将如何影响测试和开发工作流程 - 即。使用大量的组合，而不是继承具体的实现，以便很好地重用。

对于 Web 应用 - 一个好的应用服务器可以帮助进行会话变量复制，一个好的负载均衡器可以正常工作。在某些方面，通过 REST（或您选择的 Web 服务方法）使用它是编写多线程服务的简单方法。但它将对性能产生影响。同样取决于您的问题域。

消息服务（例如jms）通常用于在不同服务之间引入松散耦合。使用一个体面的消息服务器，您可以做很多msg路由（再次apache骆驼或类似工作做得很好），即。比如说，一个针对 jms 生产者集群的粘性消费者等，也可以实现良好的故障转移。Jms队列等可以提供一种简单的方法在集群中分发cmds，主/从。（同样，这取决于您是在做LOB还是从头开始编写服务器/产品）。

（如果我以后有时间，我会整理，也许在修复拼写语法等中放一些更详细的信息）

创建可靠软件的一种方法是仅崩溃软件：

仅崩溃软件是安全崩溃并快速恢复的软件。阻止它的唯一方法是使其崩溃，而启动它的唯一方法是恢复。仅崩溃系统由仅崩溃组件组成，这些组件与可重试请求进行通信。通过崩溃并重新启动故障组件并重试任何超时的请求来处理错误。生成的系统通常更加健壮和可靠，因为崩溃恢复是开发过程中的一等公民，而不是事后的想法，并且您不再需要额外的代码（以及相关的接口和错误）来显式关闭。所有软件都应该能够安全崩溃并快速恢复，但仅崩溃软件必须具有这些质量，否则它们的缺乏很快就会变得明显。