快速重启技术，而不是保持良好的状态(可用性和一致性)

Question

通过重新启动计算机、路由器、程序、浏览器来解决问题的频率有多大？甚至通过重新安装操作系统或软件组件？

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

我听说Amazon/Google有一个由许多节点组成的集群。每个节点的一个重要属性是它可以在几秒钟内重新启动。因此，如果其中一个失败了，那么将其返回到初始状态只是重新启动它的问题。

是否有任何语言/框架/设计模式利用这种技术作为一个一流的公民？

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

Answer 1

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

你可能会对一个研究小组感兴趣。他们一直在研究面向恢复的计算或“中华民国”。我国最重要的原则是，任何程序都能处于最干净、最好、最可靠的状态是在启动之后。因此，在检测故障时，他们倾向于重新启动软件，而不是尝试从故障中恢复。

听起来很简单，对吧？好吧，大部分的研究都是为了实现这个想法。原因就在于您和其他评论者所指出的:操作系统重新启动太慢，无法成为可行的恢复方法。

中华人民共和国依靠三个主要部分：

1. 一种尽早发现故障的方法。
2. 一种在保留系统其余部分的同时隔离故障部件的方法。
3. 组件级重新启动。

中华民国和典型的“夜间重新启动”方法真正的区别在于，重新启动是一种反应策略。我的意思是，大多数软件的编写都有一定程度的错误处理和恢复(抛出捕获、日志记录、重试循环等)。ROC程序将检测故障(异常)并立即退出。把这两种模式混为一谈只会让你陷入两个世界中最糟糕的境地--低可靠性和错误。

Answer 2

这在unix/linux世界中是非常罕见的。这些操作系统的设计(窗户也是如此)是为了保护自己不受行为不良的进程的影响。我相信谷歌并不是依赖于艰难的重启来纠正错误的软件。我想说的是，这种技术不应该使用，如果有人说，最愚蠢的途径，为他们的软件，你应该寻找其他东西！

Answer 3

微控制器通常有一个看门狗定时器，它必须每隔一段时间被重置(通过代码行)，否则微控制器就会重置。这可以防止固件陷入无穷无尽的循环，等待输入等等。

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