Sriram Subramanian ( niledatabase 的创始人) 关于构建高可用系统的一些思考
-------------------------
这是一篇长文，是我在过去几十年构建大规模数据库和存储系统的经验总结和随想。
在超大規模（例如，超过10,000个节点）的系统中，故障随时都在发生。关联性故障（Correlated failures）甚至更为常见。在这样的规模下，要实现所有客户集群的零宕机时间是不切实际的。因此，所有的焦点都应该放在如何减小“爆炸半径”（blast radius）上。
所谓的“爆炸半径管理”（blast radius mgmt），指的就是减少受影响的客户数量，或降低某个特定客户受影响的操作百分比。
当您设计容错系统时，可以思考以下一些技术：
💥 实例崩溃（低爆炸半径）：您通常会故障转移（failover）到另一个实例。对于有状态系统，这通过复制（replication）来实现。对于无状态系统，则是将连接重新平衡（rebalancing）到其他可用实例。如果连接本身是有状态的，那么重新建立连接会变得很棘手。此外，如果一个实例正在为多个客户提供服务，您不会希望将所有负载都转移到另一个实例上，从而导致该节点饱和。您需要将负载重新分配到多个实例上。
⚙️ 实例的某个子系统故障（低爆炸半径）：例如，某个特定的卷（volume）可能会失败。在这种情况下，您通常也会选择直接关停整个实例并故障转移到另一个。因为处理局部故障（partial failures）比处理完全故障（full failure）更麻烦。这里适用第一点中的故障转移规则。
⚠️ 多个实例同时故障（中等爆炸半径）：对于有状态系统，这归结为您愿意设置多少个副本（replica）。这变成了一个成本与可用性之间的权衡问题。同时还存在延迟问题。通过复制，您的写入延迟将取决于写入法定数量（write quorum）中最慢的那个副本的延迟。副本越多，法定数量中至少包含一个慢副本的概率就越大。对于无状态系统，您需要有足够的容量来承接故障实例的负载。一个好的系统建模方式是，预先决定系统应该能够承受多少个关联性故障。例如，N
