您多久通过重新启动计算机、路由器、程序、浏览器来解决问题？或者甚至通过重新安装操作系统或软件组件？
当怀疑软件组件没有以正确的方式保持其状态时，这似乎是一种常见的模式，然后您只需通过重新启动组件来获得初始状态。
我听说 Amazon/Google 有一个由许多节点组成的集群。每个节点的一个重要属性是它可以在几秒钟内重新启动。因此，如果其中一个失败，那么将其恢复到初始状态只是重新启动它的问题。
是否有任何语言/框架/设计模式可以利用这种技术作为一等公民？
编辑描述亚马逊背后的一些原则以及可用性和一致性的总体原则的链接：http: //www.infoq.com/presentations/availability-consistency
这在 unix/linux 世界中实际上是非常罕见的。这些 ose 被设计为（窗户也是如此）以保护自己免受不良行为的影响。我确信谷歌不依赖硬重启来纠正行为不端的软件。我会说不应该使用这种技术，如果有人说他们的软件恢复的最快途径，你应该寻找别的东西！
微控制器通常有一个看门狗定时器，它必须经常（通过一行代码）重置，否则微控制器将重置。这可以防止固件陷入无限循环、卡住等待输入等。
未使用的内存有时会设置为导致复位的指令，或跳转到微控制器在复位时开始的同一位置。如果它以某种方式跳转到程序存储器之外的位置，这将重置微控制器。
这在嵌入式系统领域和电信领域很常见。它在基于服务器的世界中不太常见。
有一个您可能感兴趣的研究小组。他们一直致力于面向恢复的计算或“ROC”。ROC 中的关键原则是任何程序可以处于的最干净、最好、最可靠的状态是在启动之后。因此，在检测到故障时，他们更愿意重新启动软件而不是尝试从故障中恢复。
听起来很简单，对吧？好吧，大部分研究都在实施这个想法。原因正是您和其他评论者所指出的：操作系统重新启动太慢而不能成为可行的恢复方法。
ROC 依赖于三个主要部分：
ROC 与典型的“夜间重启”方法之间的真正关键区别在于，ROC 是一种策略，重启是一种反应。我的意思是，大多数软件都是用某种程度的错误处理和恢复（抛出和捕获、日志记录、重试循环等）编写的。ROC 程序会检测到错误（异常）并立即退出。混合这两种范式只会给你留下两全其美的结果——低可靠性和错误。
嵌入式系统可能具有检查点功能，其中每 n 毫秒保存一次当前堆栈。内存在电源重启时是非易失性的（即电池供电），因此在电源启动时，会进行测试以查看代码是否需要跳转到旧的检查点，或者它是否是新系统。
我猜测亚马逊/谷歌使用了类似的技术（但更复杂）。
虽然我想不出设计模式本身，但根据我的经验，这是开发人员“选择被破坏”的结果。
我见过一个 50 用户的站点，因为糟糕的连接管理加上过多的调用和没有缓存而导致 SQL Server Enterprise Edition（具有 750 MB 数据库）和 Novell 服务器瘫痪。根据开发人员的说法，Novell一直是罪魁祸首，直到我们在核心库中发现缺少的“CloseConnection”调用。到那时，已经花费了数千美元进行升级以解决缺少的代码行。
（为什么他们有企业版超出了我的理解，所以不要问！！）
如果您查看在 Apache 上运行的 php 等脚本语言，每次调用都会启动一个新进程。在基本情况下，进程之间没有共享状态，一旦调用完成，进程就会终止。
优点是资源管理的责任较小，因为它们将在流程完成时释放，并且由于流程设计为快速失败并且不能处于不一致状态，因此对错误处理的需求较少。
我已经在应用程序级别的几个地方看到过它（如果应用程序爆炸，应用程序会自行重启）。
我已经在应用程序级别实现了该模式，其中从 Dbase 文件读取的服务在读取 x 次后开始出现错误。它查找抛出的特定错误，如果发现该错误，服务会调用控制台应用程序，该应用程序会终止进程并重新启动服务。它很笨拙，我讨厌它，但是对于这种特殊情况，我找不到更好的答案。
请记住，IIS 有一个内置功能，可以在某些条件下重新启动应用程序池。
就此而言，重新启动服务是 Windows 上任何服务的一个选项，作为服务失败时要采取的操作之一。