快速重启技术而不是保持良好状态（可用性和一致性）

Question

通过重新启动计算机，路由器，程序，浏览器，您多久解决一次问题？或者甚至重新安装操作系统或软件组件？

当怀疑软件组件没有以正确的方式保持其状态时，这似乎是一种常见的模式，然后通过重新启动组件来获得初始状态。

我听说亚马逊/谷歌拥有许多节点的集群。每个节点的一个重要特性是它可以在几秒钟内重启。因此，如果其中一个失败，那么将其恢复到初始状态只是重新启动它。

是否有任何语言/框架/设计模式将这项技术作为一流公民？

编辑描述亚马逊背后的一些原则以及可用性和一致性的整体原则的链接： http://www.infoq.com/presentations/availability-consistency

Answer 1

这在嵌入式系统领域和电信领域都很常见。它在基于服务器的世界中并不常见。

有一个你可能感兴趣的研究小组。他们一直致力于面向恢复计算或“ROC”。 ROC的关键原则是任何程序可以在最快，最好，最可靠的状态下启动。因此，在检测到故障时，他们更愿意重新启动软件而不是尝试从故障中恢复。

听起来很简单，对吗？那么，大部分研究已经用于实现这个想法。原因正是您和其他评论者指出的：操作系统重启速度太慢，无法成为可行的恢复方法。

ROC依赖于三个主要部分：

1. 尽早检测故障的方法。
2. 在保留系统其余部分的同时隔离故障组件的方法。
3. 组件级重启。

ROC与典型的“夜间重启”之间的真正关键区别。方法是ROC是一种重新启动反应的策略。我的意思是大多数软件都是用一定程度的错误处理和恢复（抛出和捕获，记录，重试循环等）编写的。一个ROC程序会检测到错误（异常）和立即退出。混合这两种范式只会让你感受到两个世界中最糟糕的 - 低可靠性和错误。

Answer 2

这在unix / linux世界中实际上是非常罕见的。那些were被设计（窗口也是如此）以保护自己免受不良行为的影响。我相信谷歌不依赖硬重启来纠正错误的软件。我会说这种技术不应该被采用，如果有人说他们的软件恢复的最佳途径，你应该寻找别的东西！

Answer 3

微控制器通常有一个看门狗定时器，必须经常复位（通过一行代码），否则微控制器将复位。这样可以防止固件陷入无限循环，等待输入等等。

有时将未使用的存储器设置为一条指令，该指令会导致复位或跳转到复位时微控制器启动的相同位置。如果它以某种方式跳转到程序存储器之外的位置，这将重置微控制器。

Answer 4

嵌入式系统可能具有检查点功能，每隔n ms，保存当前堆栈。 电源重启（即备用电池）时内存是非易失性的，因此在电源启动时，会进行测试以查看代码是否需要跳转到旧检查点，或者是否是新系统。

我猜想亚马逊/谷歌会使用类似的技术（但更复杂）。

Answer 5

虽然我根本无法想到设计模式，但根据我的经验，这是“选择被打破”的结果。来自开发者。

我已经看到一个50个用户的网站削弱了SQL Server企业版（带有750 MB数据库）和Novell服务器，因为连接管理不佳加上过多的呼叫和没有缓存。根据开发人员的说法，Novell始终是总是的罪魁祸首，直到我们发现缺少“CloseConnection”。打电话给核心图书馆。到那时，成千上万的人花了不成功的时间进行升级，以解决那一段缺失的代码。

（为什么他们有企业版超出我的要求，所以不要问!!）

Answer 6

如果你看一下像在Apache上运行的php这样的脚本语言，每次调用都会启动一个新进程。在基本情况下，进程之间没有共享状态，一旦调用完成，进程就会终止。

优点是资源管理的负担较少，因为它们将在流程完成时释放，并且由于流程设计为快速失败并且不能保持不一致状态，因此不需要错误处理。

Answer 7

我已经在应用程序级别看到了一些地方（一个应用程序重新启动，如果它炸弹）。

我已经在应用程序级别实现了该模式，其中从Dbase文件读取的服务在读取x次后开始出错。它查找抛出的特定错误，如果发现该错误，则该服务会调用一个控制台应用程序来终止该进程并重新启动该服务。它是kludgey，我讨厌它，但对于这种特殊情况，我找不到更好的答案。

请记住，IIS具有内置功能，可在特定条件下重新启动应用程序池。

就此而言，重新启动服务是Windows上任何服务的选项，作为服务失败时要采取的操作之一。