我见过很多网站以不太理想的方式实现。其中一个属于一个客户，该客户拥有来自其所有安装的源源不断的输入点击数据。他们有6台Web服务器位于负载均衡器后面，所有服务器都在向数据库写入数据。问题是，虽然5到6台机器可以跟上负载，但4台或更少的机器却无法承受。他们需要解决问题。
当事情变得糟糕的时候，他们会变得非常丑陋。让我们假设一切开始都很顺利。所有六台机器都在嗡嗡作响，处理着负载。然后一些不好的事情发生了，其中一个退出了。现在有五台机器在处理货物，每一台都接过了一些闲置的东西。他们现在正处于临界点。现在又有一个人死了。现在重新平衡到剩余四台机器的负载实在太大了，结果它们都死了。
头几次发生这种情况时，他们打来电话，要求重新启动他们的机器。数据中心人员确实做到了这一点，推出了一辆急救车，并按顺序重新启动。因此，它们将开始重新启动，并按顺序重新启动Apache。一旦发生这种情况，他们的负载均衡器就会开始向那个*一个*Web服务器发送流量。不出所料，它就会死去。然后，第二台重新启动的机器会出现并被砰的一声撞上，然后就会死掉，以此类推。
它终于到了必须遵循整个荒谬过程的地步。首先，需要禁用负载均衡器，这需要给实际管理这些设备的人员打电话。接下来，必须重新启动所有Web服务器，并且必须修复配置中的任何问题。只有在所有人都健康的情况下，才能重新启用负载均衡器的VIP。这非常耗时、容易出错，而且手工操作非常烦人。
我听说了这一切，然后说，天哪，大多数运营网站的人都想要高可用性和心跳。你们需要的是当它“真的”坏了的时候尽量减少停机时间，而你们真的需要一个自杀协议。我把它描述为这样一个系统，在这个系统中，每台主机都会监控自己的Web服务器，并会发出一个信标，说它是健康的。其他每个系统都会监视这些信标，并跟踪谁还活着。
如果由于某种原因，整个系统低于某个阈值(称其为最小阈值，称其为quorum，等等)，那么剩余的所有主机都会故意杀死Apache。当然，这让网站瘫痪了，但这意味着事情会更快地恢复过来。这是可能的，因为只需要重新启动最少数量的机器，并且整个切换负载均衡器的事情不必发生(两次)。
我们最终把它作为浪涌保护器卖给他们，给它的二进制命名，但每个人都知道它的意思。顾客很喜欢。在接下来的几周里，他们极大地扩展了配置，并开始处理更多的流量，因为他们不再害怕过多的流量会发生什么。
当然，他们可以重写他们的网站代码，这样就不会让机器陷入一场数GB深的交换狂欢。他们本可以在没有任何东道主参与的情况下做到这一点。他们没有，所以现在我有了一个故事，讲的是我有一次故意设计了一些东西，用令人发痒的扳机手指杀死一个网站，并很高兴地让客户为此买单。