Fault tolerance（容错）是否必然提供High availability（高可用性）？

Fault tolerance（容错）系统不一定能提供High availability（高可用性）。二者是强相关但设计目标、覆盖范围、评价标准完全不同的技术概念，不存在“有容错就一定有高可用”的绝对推导关系。

把二者的核心评判标准理清楚，就很容易想明白为什么不能划等号：

• 容错的核心目标是消除系统单点故障：单个硬件、软件组件发生故障时，系统可以通过冗余机制无缝承接业务流量，全程不出现服务中断，用户完全感知不到故障发生。它是针对「单点故障场景」的二元能力判断——要么具备该能力，要么不具备。
• 高可用的核心目标是最大化服务正常运行的时间占比：也就是常说的uptime指标，最高等级的99.999%可用性要求全年累计停机时间不超过5分钟。它是覆盖全场景的量化指标，所有会导致服务无法正常访问的因素都在考核范围内，和具体用什么技术实现没有绑定关系。

SNIA提到的“高可用大多通过容错能力实现”，只是说明容错是建设高可用系统的常用手段之一，绝非充分条件。容错只覆盖了「单点组件故障」这一种会导致停机的场景，而实际生产环境里能造成服务停机的问题要多得多，容错系统如果没覆盖到这些场景，照样达不到高可用标准：

• 最常见的是计划内停机问题：很多传统强同步锁步容错系统，做固件升级、版本迭代、安全补丁更新的时候，必须把所有冗余节点整体停机才能操作，一次升级就要停机十几到几十分钟。一年光计划内运维的停机时长就远超99.999%要求的5分钟阈值，哪怕它应对硬件故障的能力再强，也达不到最高等级的高可用要求。
• 其次是容错设计的覆盖范围不足：比如有些双控制器容错存储，确实做到了控制器、电源、硬盘全冗余无单点，但是没有设计过载限流能力，遇到业务流量突增时所有冗余节点都被打满，请求全部超时，服务完全不可用；或是遇到软件逻辑bug、数据损坏问题时，冗余节点会同步执行错误逻辑，一起发生故障。这类场景下系统虽然满足容错的定义，依然会出现长时间服务中断。
• 还有容错架构本身的性能瓶颈问题：部分强同步容错系统为了保证多节点状态完全一致，会引入很高的同步校验开销，当业务负载超过设计阈值时，系统响应延迟会飙升到用户无法接受的程度，从用户视角看服务已经不可用，自然也谈不上高可用。

反过来补充一个工程常识：高可用也不一定要靠严格的容错实现。比如现在互联网行业常用的主从故障自动切换架构，主节点故障时从节点升主需要几秒到几十秒的切换时间，期间会有短暂的服务中断，不属于严格意义上的容错系统，但只要全年累计的切换中断、计划内停机、其他故障停机的总时长达标，照样可以拿到对应等级的高可用评级。

内容的提问来源于stack exchange，提问作者akhmad fadil Mubarok