53 | 过载保护与容量规划

天呐，这么好的内容怎么没几个人交流呢。 前一段时间微信支付故障，前端没有关闭微信支付通道，后端其他逻辑因为失败在疯狂重试（不是有节奏的延长重试时间），服务端也没有做限流，差点导致悲剧。 过载保护确实很重要。 对于老师说的:基于QPS还是基于资源使用率，我们常规压测是基于QPS。容量规划上可以容忍一半的机器故障。

1、技术的价值是在业务中体现的，业务系统出现问题时，要忍住自己查到问题根源的冲动，第一时间恢复业务。这是技术人员成长的必经之路。 2、在做好熔断降级策略之前，重试策略会将问题放大，很容易就成为雪崩的罪魁祸首。 3、在雪崩的时候，服务的自动恢复，业务的自动重试，会导致雪崩不止。 4、容量规划时，同时也要考虑业务的特性，是高CPU服务，还是高IO服务。不同类型服务，线程数设置、监控指标，熔断降级策略要有不同的考量。 5、多机房的一个大问题是数据同步，流量问题反而有更成熟的方案。

许老师，这几讲读下来，有一个疑问请教下： 每个人所处的项目规模有很大的不同，有的没做服务化还在跑负载均衡、有的可能到了七牛云的体量、有的可能是微博那种体量，另外就是人力可能也不允许，那么有什么衡量指标或依据可以判断一个服务端相关的SRE工作是否做到位？以此指导每个阶段应该做哪些最主要的事情？谢谢

老师，请问重试是将请求失败的请求用代码直接再次发起请求吗？这会增加代码量，怎么判断一个接口需不需要重试的机制呢？

关于重试这一块，我还有点心得。就是在编码的时候，要求团队对 api 返回的错误甄别，如果是系统未知错误就不重试。如果是类似于远程连接失败，规定时间超时，等网络层面而非业务逻辑层面的就要重试。但是也有如下问题 1、基于 QPS 这个我知道，但是基于资源使用率，这个数据是如何得来的？前者可以通过站点访问统计得知，后者呢？ 2、“为每个用户设置独立的负载配额”，“当某个客户端检测到，最近的请求错误中的一大部分都是由于 “配额不足”错误导致时，该客户端就开始自行限制请求速度，限制它自己生成请求的数量” 这里我没懂，这里的负载配额是说什么？指分配如运存之类的资源？如何在一个正在运行的 app 中的用户设置所谓的“负载配额”呢。 这方面属于什么范畴，我想查资料了解下。我都不知道怎么查关键字搜资料了

负载均衡处的过载保护是怎么做的？

用量的确很好 更好的解决方案，是直接基于该服务所依赖的关键资源，如 CPU 和内存等，来衡量服务的可用容量。我们为该服务预留了多少资源，这些资源已经用了多少，预计还能够用多久。

学习打卡

这一节很不错。指数等待重试、本地自适应拒绝、优化手段可能会导致大故障。

过载问题是由于用户增长量大大超过预期而导致，后台CPU的使用率达到100这个时候它的处理速度就非常的慢，再加上服务端的缓存机制和并发处理机制，不会在第一时间就拒绝请求，还是正常接受请求直到所有资源都被填满。 之前遇到过，因为频繁重复访问而导致数据库服务崩溃的情况，比如有一个定时任务因为执行失败而不断的重复执行，请每一次执行都要使用数据库资源，且在执行失败的时候没有来得及释放资源。然后就会导致数据库连接直接爆表。这个时候要么重启数据库，重置连接数，要么停掉这个服务来断开连接。 关于CPU的使用率达到100的情况，以前在工作中遇到过，就是在基于库表进行数据抽取清洗的时候，有三个程序并发的给数据库写入数据，这个时候安装数据库的那台服务器的CPU直接100%，速度特别的慢，最后是将数据库的资源进行扩容之后，才解决了这个问题。 老师今天讲的客户端节流策略，不知道是针对每一个用户的请求来节流呢，还是对整个客户端的请求来做一个节流，比如说按照某种标记，只发送重要请求，如果是按照按照用户来做，那么可能就只有VIP用户的所有请求能发送成功了，在系统过载的情况下。