我在接受采访时被问到了这个问题：
我有一个SQL服务器和一个asp.net应用程序。 即使服务器崩溃，我也要为我的应用程序提供24X7小时的可用性。
在代码级别和更高级别（不在代码级别）实现它有什么不同的方法？
最终它会归结为金钱。 在神话般的“五个九”（99.999％的可用性，每年5分钟的停机时间）中，每个“九”都有成本，而且成本相当高。 99.999％的可用性系统成本为百万美元，必须包括硬件，软件许可证，专门训练有素的专业人员，培训，程序等等。 您必须考虑系统更新（操作系统和供应商补丁），应用程序升级，数据库重新索引等各种维护程序等。
但是，对于一个非常粗糙的答案，我会指出您的高可用性解决scheme概述 ：
- 故障转移群集
故障转移群集为整个SQL Server实例提供高可用性支持。 故障转移群集是一个或多个节点或服务器与两个或多个共享磁盘的组合。 每个应用程序都安装在Microsoft群集服务（MSCS）群集组中，称为资源组。 任何时候，每个资源组都只能由集群中的一个节点拥有。 应用程序服务具有独立于节点名称的虚拟名称，称为故障转移群集实例名称。 应用程序可以通过引用故障转移群集实例名称连接到故障转移群集实例。 应用程序不必知道哪个节点承载故障转移群集实例。
- 数据库镜像
数据库镜像主要是通过支持几乎即时的故障转移来提高数据库可用性的软件解决scheme。 可以使用数据库镜像来为相应的生产数据库（称为主数据库）维护单个备用数据库或镜像数据库。
- 日志传送
与数据库镜像一样，日志传送在数据库级别运行。 您可以使用日志传送来维护被称为主数据库的相应生产数据库的一个或多个热备份数据库。 备用数据库也被称为辅助数据库。 每个辅助数据库都是通过恢复主数据库的数据库备份而不创build恢复或备用数据库来创build的。 使用备用恢复可让您使用生成的辅助数据库进行有限的报告。
- 复制
复制使用发布 – 订阅模型。 这使主服务器（称为发布服务器）可以将数据分发到一个或多个辅助服务器或订阅服务器。 复制可以实现这些服务器的实时可用性和可扩展性。 它支持过滤，以在Subscribers上提供数据的一个子集，并允许分区更新。 用户在线并可用于报告或其他function，无需查询恢复。 SQL Server提供三种types的复制：快照，事务和合并。 事务复制提供最低的延迟，通常用于高可用性。
我不认为在这里有很多人会给你一个面试问题的答案，帮助你通过它虚张声势，而且我相信这不是你的意思，所以这里有两个学习的select。
Google“高可用性asp.net”。 （“高可用性”是您正在寻找的术语）
看这个video
在代码级别上，你可以做的事情不多：如果你的服务器崩溃，就会崩溃。 在硬件方面，他们可能正在寻找像故障转移群集这样的短语。
它需要多个服务器，这对某些人来说是不可行的，可能并不是必须的。 但是，如果关键是达到接近100％的正常运行时间，则在服务器级别有一个称为“ 故障转移群集”的function，当服务器出于各种原因而崩溃时，其他服务器中的一台会“跳入”并接pipe。
具有容错（FT）function的VMware vSphere或其他虚拟化产品的等效function。 这个解决scheme不限于2台服务器（一台服务器出现故障，另一台服务器负载），但是可以分配给多台服务器。 这只是一个你想花多less钱的问题。
这完全是与操作系统无关的，这意味着您可以让您的应用程序在Windows Server上运行，并且您的数据库在Linux RedHat上运行，反之亦然。
如果你的asp.net应用程序和数据库在两台服务器上都有一个热切换选项，那么这两个服务器将会提供更高的响应性。 但是，您还需要考虑数据库服务器是否出现故障排队，以及数据库何时恢复，以FIFO方式提交事务。
一般来说，扩展就是我将如何回答这个问题，但我同意@CXFX完全在代码级别完成它是不可能的。
在实际业务中，我会看：
但是这不是Stackoverflow的情况。
这不是一个快速的答案，因为要真正掌握数据中心，平台和应用程序级别的高可用性需要进行大量的现实学习。 高层次，这里有一些事情要考虑。
为了抵御服务器崩溃和修补，您需要在站点级别进行负载平衡，某种SQL高可用性解决scheme以及未locking到单个服务器的应用程序。
对于站点级别，有许多第三方负载均衡器本身是冗余的。 或者，微软的应用程序请求路由（ARR）解决scheme也是一个不错的select。
对于SQL Server来说，内置的集群，镜像或日志传送选项通常符合这一要求，另外像DoubleTake这样的产品在满足这种需求方面做得非常出色。
在应用程序级别，您需要确保没有任何东西取决于单个节点。 会话状态是最常见的依赖项。 如果使用它，则需要将其卸载到冗余解决scheme。 SQLServer会话状态，ScaleOutSoftware和现在AppFabric都是要考虑的选项。
真正的冗余需要在数据中心之间进行地理冗余，这些数据中心需要足够的距离，以免受到任何重大自然灾害的影响。
而且，没有技术就没有足够的testing和大量的stream程和程序来了解如何尽可能顺利地处理突发情况，并定期testing系统的各种冗余部分。