需要多少台服务器
场景 1：丢失一个节点
假设你正在开发一个预计每秒处理 1000 个请求（QPS）的服务，而且我们假设服务中的单个节点每秒只能处理 300 个请求。
问题：你需要多少个节点才能支撑该流量？
所需节点数量 = 1000/300 ≈ 3.3 = 4 个节点如果你在流量峰值时丢失 1 个节点，你的服务会失败。为什么？因为如果丢失1个节点，你的流量会分布在剩余 3 个节点上。此时：
每个节点处理的请求数量 = 请求总数/节点数量 = 1000 / 3 = 333每个节点需要每秒处理 333 个请求，这超过了每秒 300 个请求的节点限制，服务器已经过载。
为了能够处理节点故障，你需要 4 个以上的节点。如果你希望能够处理 1 个节点故障，那么就需要 5 个节点。这样，即使 5 个节点中的其中 1 个出现故障，还剩下 4 个节点可以处理流量。
场景 2：升级过程中出现的问题
假设你有一个平均流量为每秒 1000 个请求的服务，且假定服务中单个节点的处理上限是每秒 300 个请求。
如之前的示例所述，最少需要 4 个节点来运行服务。为了能够处理预期流量并支持单节点故障，你为服务配置了 5 个节点。
现在，假设你希望对正在运行的服务进行一次软件升级。为了在升级过程中保证服务正常运行，你决定使用滚动部署的方式。每次只升级 1 个节点，在成功升级第一个节点并重新处理流量之后，继续升级第二个节点，持续这个过程直到 5 个节点都完成升级。
因为在每次升级时，只有 1 个节点是离线状态，所以总是有 4 个节点在处理流量。因为 4 个节点已经足够处理所有的流量，所以升级过程中服务不会受到影响。
如果在升级过程中某个节点发生了故障呢？这个时候，你有 1 个节点因为升级不可用，还有 1 个节点出现故障，这样只剩下 3 个节点，不足以处理所有的流量。这时，你就会遇到服务降级或者系统整体不可用的情况。
因此，要想使用每秒 300 个请求的节点来处理每秒 1000 个请求的流量，我们需要：
4 个节点
可以处理流量，但是不能处理单个节点故障。
5 个节点
可以处理单个节点故障，或者在维护或升级时允许单个节点不可用。
6 个节点
可以处理多个节点故障，或者在维护或升级时允许同时存在 1 个节点升级失败和 1 个节点不可用。
我们得到的教训是：
即使你认为有冗余节点来处理各种故障情况，但是如果有两个或多个问题同时发生（因为问题都是有关联性的），就可能会根本没有任何冗余。这样的系统就容易出现可用性的问题。
场景 3：数据中心恢复
假设你的服务正在处理每秒 10,000 个请求的流量。因为单个节点每秒只能处理 300 个请求，所以这意味着你需要 34 个节点，这还不考虑故障冗余和升级的情况。
为了让系统增加一些额外的处理能力，我们使用了总共 40 个节点（每个节点每秒处理 250 个请求）。现在即使失去多达 6 个节点也可以处理所有的流量。我们把这 40 个节点平均分布到 4 个数据中心，这样可以有更好的冗余性。
显然，我们可以处理单个节点故障，因为我们已经提供了额外的 6 个（40 - 34）节点。但是如果某个数据中心出现故障了怎么办？
如果某个数据中心出现故障，我们就丢失了四分之一的服务器。在这个例子中，我们就从 40 个节点减少到了 30 个节点。此时每个节点不再每秒只需处理 250 个请求了，而是需要每秒处理 333 个请求。因为这超过了单个节点的处理能力，所以我们又遇到了可用性的问题。
显然，即使 4 个数据中心其中之一出现故障，我们需要确保任何时候都拥有 34 台正常工作的服务器。这意味着我们需要有 34 台服务器遍布在其他 3 个数据中心中：
每个数据中心的节点数 = 服务器最小数量 / (数据中心数量 - 1) = 34 / ( 4 - 1) ≈ 12因为我们需要在每个数据中心有 12 台服务器，并且即使 4 个数据中心之一出现故障，我们在每个数据中心仍然有 12 台服务器，所以：
总节点数 = 每个数据中心的节点数 × 4 = 48因此，我们需要 48 个节点来保证，即使有 1 个数据中心出现了故障，依然有 34 个节点能够工作。