高可用与容灾：超时、重试、熔断、降级、限流

高可用与容灾：超时/重试/熔断/降级/限流一、从一次大促开始想象一下这个场景。双11零点，某电商App涌入平时50倍的流量。·有些接口直接返回429(TooManyRequests),"操作太频繁";这不是"后端服务器质量参差不齐",而是设计好的分层策略。工程师不这一篇讲清楚这五个概念——超时、重试、熔断、降级、限流——以及它们组合起来是怎么让一个系统"胆小但不倒"。二、五层防护：从外到内的闸门线上系统的高可用不是靠"一个魔法开关",而是五层各司其职的闸门，一层放行才走下一层：①网关层限流：拦在门口用户流量到达后端的第一站是网关。这里做的是粗粒度限流：·按IP限流：单个IP每秒最多100个·按用户限流：单个账号每分钟最多下单10次，防羊毛党·按API限流：某个昂贵接口全局每秒最多处理1000个请求，防打爆三种常见算法(你不用会实现，会说是哪种就行):时可以一下用光)大多数场景用令牌桶——既能限总量又能容忍突发。服务A依赖服务B,B突然挂了。如果A还傻乎乎地一直请求B,会发生什么?**熔断(CircuitBreaker)**就是保险丝：B连续失败超过阈值(比如50次/10秒),熔断器"打开",A之后调用B直接失败返回(不再真的发请求过去)。等一段时间再"半开"试探性放几个请求过去；如果B恢复了就关闭熔断，恢复正常。核心思想：下游挂了，我不陪它一起挂。③应用层降级：主动关闭非核心功能大促期间流量太大扛不住，怎么办?主动降级——关掉一些非核心功能给核心让路：·关闭商品详情页的"相关推荐"(一个接口打不动→少展示一个模块)·关闭订单历史列表的分页(只显示最近7天)·关闭评论加载(先看到商品即可)核心链路(登录→浏览→加购→下单→支付)必须保，其他都降级和熔断的区别：熔断是被动的(下游挂了才断),降级是主动的(预判扛不住主动关)。④调用层超时：别死等所有网络调用都必须设超时。这是所有防护的基础，缺了它，前面所有想象一下：设置的超时是"无限"。下游卡住了，你就死等；线程被卡死；线程池打满；新请求进不来；应用假死。没有超时=漏水的水管。合理的超时时间是这样估的：·后端要调3个下游：每个下游500ms·每个下游内部再调数据库：每次100ms⑤DB连接池隔离：慢查询不能拖死全站数据库连接是稀缺资源(通常一个应用实例分配20-50个连接)。如果所有业务共用一个连接池：·报表业务的一个慢SQL占了5个连接跑了30秒做法：给关键业务分独立连接池——下单/支付独占20个连接，报表用另一个10个连接。互不影响。三、重试是把双刃剑：无脑重试=加害新人最容易犯的错——"接口失败就重试"。听起来天经地义，但在分布式系统里，无脑重试是雪崩的第一推手。重试风暴是怎么发生的B→数据库)。每一层都写了"失败重试3次",看起来很稳。现在数据库因为一个慢SQL变慢了。会发生什么?收到9倍压力·BFF调A全都超时，重试3次→DB收到27倍压力·前端调BFF全都超时，重试3次→DB收到81倍压力本来只是慢一点的DB,被这波"友军"直接打死。这就是重试风暴。正确的重试姿势·只在幂等接口上重试：读接口一般幂等；写接口要看设计(后面05篇会展开讲幂等)·指数退避+随机抖动：第1次失败等1秒，第2次等2秒，第3次等4秒；每次加个随机偏移(避免所有客户端同步重试)什么时候不该重试·明确的4xx错误(参数错、鉴权失败):重试也是同样的错，只是浪费资源·业务失败(库存不足、余额不够):重试没意义只有"看起来是临时故障"的错误才重试——超时、5xx、连接失败。四、案例拆解：一次因为"少设一个超时"引发的全站宕机真实故障(改编)。某社交App的动态流服务：架构：动态流服务调用6个下游服务(用户、内容、关注关系、点赞、评论、推荐)拼接首页流。每个下游调用都设了500ms超时。变更：新加了一个"广告服务"作为第7个下游，负责在流里插入广告。这个服务是新团队做的，接入时忘了设超时——用了默认值，默认是没故障日：广告服务因为一个bug卡住了，请求进去不返回。3.5分钟后，动态流服务的线程池打满(一共200个线程，全在等广告服务)教训：断打开30秒；30秒后放3个请求探测；探测成功了才恢复正常。之后广告这个案例几乎是所有微服务架构一定会遇到的坑，只是发生在早还是晚。五、SLO:可用性到底怎么衡量聊高可用绕不开SLO(ServiceLevelObjective)—行业里常见的可用性目标：每年停机时间3.65天玩具项目99.9%(三个9)8.76小时一般SaaS99.99%(四个9)52.6分钟主流互联网产品99.999%(五个9)5.26分钟支付、金融核心系统关键理解：每加一个9,成本10倍。从三个9到四个9需要多机房、求五个9——一个后台管理系统追求四个9就是浪费。常用指标·可用性：成功请求数/总请求数(不是简单地"服务在线")·P50/P95/P99响应时间：50%/95%/99%的请求在多少时间内返回。P99比平均值有意义得多——平均100ms但P99是5秒，那1%的用户体验·错误率：5xx请求占比，通常控制在0.1%以下·QPS/TPS:每秒查询数/事务数，用来做容量规划六、给前端/校招同学的行动清单1.看到429、503,别当作bug。429是被限流了(可能触发了业务规则),503是后端主动降级或熔断触发。这两种响应不要疯狂重试，退避一段时间再2.前端也要做loading保护。用户点击按钮后立刻置disabled、显示load3.看到某个功能"暂时不可用",别惊慌。这可能是主动降级——后端权衡后关掉了非核心功能。你的任务是优雅提示("该功能暂时不可用，请稍后再试"),而不4.