高可用高性能系统（十一）最后的守护

在高可用性的要求下，理论上要求所有的数据、载体都必须有备份，这样就可以避免单体故障的影响，这是最基本的要求。如果在简单的系统中，这没有问题，毕竟2台或者少数的几台基本上没有什么问题。可是我们如果想象下GOOGLE那样的公司，或者大型的券商或者交易所啥的公司。双备份的要求可能会变得难以承受。

其实我们研究下双备份的缘由，可以发现，之所以要双备份，主要是希望在其中一个系统失效的情况下，另外一个系统能够及时的提供服务，而最终的目的，依然是提供服务。基于这个最终目的，我们发现，其实只要能够提供正确的服务，是否双备份并不是必然的要求。

我们考察在哪些情况下，系统失效后，依然能及时提供服务呢？

1、能很短时间内恢复服务

2、能很短时间内请求接管

    双备份的系统中，也是为了达到短时间内接管请求，但实现能接管请求的不一样是双备份系统。我们下面来讨论下如何实现非双备份的解决方案来实现双备份的功能。

首先，应大多数用程序的重启，实际上可以在几秒钟之内完成。不过很多操作系统和DBMS估计很难做到。但还是有些可以用USB/RAMDISK/LIVE-CD类型的操作系统能够实现很短时间内恢复服务。不管怎么说，只要这个系统能够在很短时间内完成服务的恢复工作，那么双备份的工作实际上没有太的必要。

其实，请求接管问题，和恢复服务很类似。通常情况下，客户端发出的请求在网络上传输时，如果接收方失效的话，请求会因无法被接收而丢失了，这种错误只能由双备份系统来挽救。但是，如果这个请求是放在某台机器的内存中，事实也不需要双备份了。因为请求能容易地被转发到其他服务器或者服务进程中。

   在这样的系统中，我们如果将每个请求以及请求的处理在时间粒度上，能够控制的比较小，这其实也涉及无状态系统的一个特性。那么双备份在大型系统中也不是很必要的。于是双备份的特性就被演化为服务恢复和请求接管的2个子问题。如果我们解决了这2个问题，那么双备份的问题就不再存在。而这2个子问题的解决方案在上面已经有了论述了。

     在大型系统中，所有的系统或者机器都能短时间恢复或者所有的请求粒度都受控制，显然是不太现实，总有些系统比较庞大，比如数据库。于是，我们就可以为这些无法解决的案例建立双备份，在这里，我称之为最后的守护。他是高可用性高性能的最小子集。在P2P网络中，实际上就是这种架构。BT种子被提交给服务器，客户端连接到服务器后，得到了种子，那么他们将通过种子中定义的跟踪服务器获取邻居的信息，然后之间互相建立连接，文件的传输过程就和服务器无关了。这种服务器就是扮演最后的守护的角色。我们只要保证这个服务是高可用的，那么后续的过程就能继续。即使传输过程中发生失效，也能重新根据服务器提供的信息继续文件传输的过程。

 

需要做最后的守护的资源一般是内容庞大，以致于无法迁移的内容，比如数据库，文件。他们大到一定程度时，由于无法被接管，所以对他们做双备份是最后的选择。