一、高可用架构概述：什么是高可用、为什么推荐服务需要高可用、可用性度量指标（如99.9%、99.99%）、CAP理论在推荐系统中的应用
1.1 什么是高可用？我的理解
高可用，说白了就是系统能不间断地对外提供服务。
我见过不少刚入行的同学，觉得高可用就是「多部署几台机器」。嗯，这话对了一半。多部署只是手段，真正的目标是：当部分组件挂了，用户几乎感觉不到。
举个例子。你打开抖音刷视频，推荐流突然卡住了——这算不算不可用？算。但如果只是后台某台服务器重启了，你完全没察觉，这就是高可用在起作用。
我个人习惯把高可用拆成两个层面：
- 服务层面：接口能正常响应，不报错、不超时
- 数据层面：推荐结果不丢失、不重复、不乱序
我在项目中遇到过一种情况：服务层面看起来一切正常，但推荐结果全是空的。用户看到「暂无推荐」四个大字，体验直接归零。所以，高可用不只是「活着」，还得「活得好」。
1.2 为什么推荐服务需要高可用？
你想想看，推荐系统在互联网产品里是什么地位？
它是流量分发的大脑。首页推荐挂了，用户不知道看什么；猜你喜欢挂了，转化率直接腰斩；搜索推荐挂了，用户找不到想要的商品。
我参与过一个电商大促项目，推荐服务在高峰期宕了8分钟。那8分钟里，首页点击率下降了40%，GMV损失了将近200万。老板在作战室里脸都绿了。
所以，推荐服务的高可用不是「锦上添花」，而是「生死存亡」。具体来说，有这几个原因：
- 流量集中：推荐接口往往是流量入口，QPS动辄上万甚至几十万
- 依赖复杂：推荐服务要调用户画像、物品库、召回模型、排序模型……任何一个下游挂了，都可能连锁反应
- 实时性要求高：用户刷一下页面，几百毫秒内必须出结果。超时就是不可用
- 业务影响大：推荐直接决定用户看到什么，进而影响点击、转化、留存
核心观点：推荐服务的高可用，本质上是「在复杂依赖链中，保证端到端的稳定输出」。
1.3 可用性度量指标：99.9% 和 99.99% 到底差多少？
很多公司喜欢用「几个9」来衡量系统可用性。但说实话，我见过不少团队把「99.9%」挂在嘴边，却不知道它意味着什么。
咱们直接看数据：
| 可用性 | 年故障时间 | 月故障时间 | 周故障时间 |
|---|---|---|---|
| 99% | 87.6小时 | 7.3小时 | 1.68小时 |
| 99.9% | 8.76小时 | 43.8分钟 | 10.1分钟 |
| 99.99% | 52.6分钟 | 4.38分钟 | 1.01分钟 |
| 99.999% | 5.26分钟 | 26.3秒 | 6.05秒 |
看到了吗？从99.9%到99.99%，年故障时间从8.76小时降到52.6分钟。这可不是线性增长，而是量级的跃迁。
我曾经带过一个推荐服务，对外承诺99.9%可用性。结果有一次模型发布出了bug，导致推荐接口返回了3个小时的错误数据。虽然服务没挂，但用户看到的是乱码推荐——这算不算可用？严格来说不算。那次事故直接让我们把SLA从99.9%提到了99.99%。
避坑指南：我曾经以为「服务没挂」就等于「可用」。后来发现，返回错误数据、返回空结果、响应超时，这些都属于不可用。度量可用性时，一定要把「正确响应」作为标准，而不是「有响应就行」。
1.4 CAP理论在推荐系统中的应用
CAP理论，做分布式系统的应该都听过：一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance），三者最多同时满足两个。
但在推荐系统里，这个理论怎么落地？我聊聊自己的理解。
1.4.1 推荐系统更看重什么？
我个人认为，推荐系统是典型的AP系统——优先保证可用性和分区容错性，对一致性要求相对宽松。
为什么？
- 用户刷推荐流，你给他返回5秒前的推荐结果，他完全没感觉
- 但如果推荐接口超时了，他立刻就会觉得「App卡了」
- 推荐结果本身就有随机性，稍微不一致不影响体验
我在项目中遇到过这样一个场景：用户画像数据更新了，但推荐服务还在用旧画像。按理说这算「不一致」。但用户看到的新推荐和旧推荐差别不大，体验上没问题。可如果为了等新画像同步，让用户多等200毫秒，那体验就差了。
1.4.2 什么时候需要强一致性？
当然，也不是所有场景都能放松一致性。比如：
- 用户屏蔽了某个物品：必须立刻生效，不能再推荐出来
- 广告推荐：预算扣减必须一致，不能超投
- A/B实验分流：用户一旦进入实验组，后续请求必须保持一致
这些场景下，我会选择牺牲部分可用性，保证强一致性。比如用分布式锁、事务消息、或者同步写主库。
我的建议：不要一刀切。推荐系统里，80%的场景可以接受最终一致性，20%的场景必须强一致。把这20%识别出来，单独做保障，比全盘追求强一致要靠谱得多。
1.4.3 实际架构中的取舍
我习惯把推荐系统的数据流分成三层：
- 离线层：每天或每小时更新一次，完全不用考虑一致性，AP即可
- 近线层：分钟级更新，接受最终一致性，AP为主
- 在线层：实时更新，部分场景需要强一致，CP或AP+补偿
举个例子。用户点击了一个物品，这个行为要实时更新到推荐模型里。但如果更新失败了怎么办？
- 如果这是「屏蔽」操作，必须重试直到成功（CP）
- 如果这是「浏览」操作，丢了就丢了，不影响大局（AP）
你看，同一个系统里，不同数据走不同策略。这就是CAP理论在推荐系统中的实际应用。
总结一句话：推荐系统的高可用，不是追求「永不宕机」，而是追求「在允许的范围内，让用户感受不到异常」。CAP理论告诉我们，没有银弹，只有取舍。
好了，这一章就聊到这儿。下一章我会讲讲推荐服务常见的故障模式，以及我们怎么从架构层面去预防。到时候我会分享一个我踩过的坑——因为缓存穿透导致整个推荐集群雪崩，那叫一个惨烈。