引言：当系统宕机时，用户要的是“能用”，不是“完美”
“硅谷有个传说，说 Amazon 把数据存到了银河系里，但 Redis 每次都往地底下钻。”这句业内调侃背后，藏着一个被无数工程师反复验证的真理：在分布式系统中，可用性（Availability）不是锦上添花的特性，而是生存的底线。
想象你正在抢购一双限量球鞋——秒杀页面加载了 10 秒仍显示“服务器繁忙”；又或者你在深夜提交报销单，系统突然弹出 502 错误。这些体验背后，往往不是架构设计失败，而是团队在“一致性”与“可用性”之间做出了主动选择。
本文将系统性拆解Cap定理中的可用性：从理论定义、工程实践、典型误区到前沿演进，结合真实场景，揭示为何在绝大多数互联网应用中，可用性被列为第一优先级。无论你是初级开发者、架构师，还是对分布式系统好奇的技术爱好者，都能从中获得可落地的认知升级。
? 用户视角的可用性
不是系统“能启动”，而是用户“能完成目标”——下单、支付、评论、上传……任何操作响应时间 ≤ 2 秒，失败率 < 0.1%，才是可用性的终极标尺。
⚡ 工程视角的可用性
系统在部分组件失效时仍能持续提供服务的能力。典型指标：99.9% 年可用性 ≈ 年停机 ≤ 8.76 小时；99.99% ≈ ≤ 52.6 分钟。
?️ 架构视角的可用性
通过冗余设计、熔断降级、异步解耦等机制，确保服务在面对网络分区、节点故障、流量洪峰时“软着陆”，而非整体雪崩。
? 关键认知
可用性 ≠ 100% 不宕机，而是：故障发生时，服务 degrade（降级）而非 fail（崩溃）。就像地铁系统——某站信号故障时，其他线路仍可运行，只是部分车次延误。