本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！ 大型电商618、11.11大促实战 (上) 讲述了“三预、三限、三降” 中的三预。
接下来总结一下三限、三降。
三限
1.限流
看到限流我们通常想到的是一些常见的限流算法，例如 令牌桶、漏桶、滑动窗口等。 但是大家有没有想过这些都是对单价或集群的限制，有没有更高层面的控制呢？ 比如负载层面用户的请求都是通过网络传输到机房,对应到机房的硬件设备负载器F5。 关于F5这里就不简述了,网络这方面资料很多。
到达机房之前网络层有没有限制有的那就是对应的网络带宽。
网络带宽是指在单位时间（一般指的是1秒钟）内能传输的数据量,如果大促期间带宽出现问题,例如带宽 如果是瓶颈造成丢包或延迟严重情况用户都打不开界面。
接下来通过硬件负载设备就到达服务器，通常服务器会有网卡、连接数限制。 这些大多不必关心，只要机器足够都不会成为瓶颈。
软件限流方面还有 HAProxy、NGINX、Tomcat。
代码层面当然也需要进行 依赖上下游的限流、单机限流、集群限流。
简述到这里如果F5出现瓶颈怎么处理呢？
域名都是通过DNS服务器进行解析的，可以对不同业务设置独立域名进行限流。
对于限流简单总结一下
用户请求域名 -> DNS服务器 -> CND加速(对于不同场景可能不存在) -> 硬件负载设备 -> 服务器 ->软负载 -> 集群 —> 单机 -> 代码层面。
熟悉整个流程后你才能知道瓶颈在哪里，如果限流和扩流。 非常重要的一点还需要考虑网络运营商方面。
2.限速
对于限速问题，可以理解为高速上的限速。
这时候对系统的处理能力方面进行控制,大多数运行的都是虚机当CPU负载过高肯定会导致物理机上 其他系统处理超时等情况。
也有一些服务是容器化上云的，可以对CPU负载进行阈值设置自动扩容。大家想一下如果短时内 请求流量峰值过高根本等不及自动扩容。
尤其是一些重要的场景下高并发操作有可能会导致连锁反应整个集群瘫痪都有可能。
这时候需要对重点系统需要使用单独物理机或者绑定指定的CPU内核处理，保证CPU处理的速率。
上述只是操作系统的层面。
这些处理好像还缺点什么那就是JVM的调优,别忘了代码是运行在JVM虚拟机上的不是直接运行在操作系统上。
3.限名单
限制黑白名单非常重要,重要场景也难免会有爬虫或者恶意攻击等等。不光需要网络安全层面考虑，一些重要的服务也需要进行考量。
很大程度上可避免资源的浪费。
经历： 曾经接触过商品系统，突然有一天流量飙升。 通过抓取IP进行分析发现有爬虫半夜爬数据,这导致整晚没睡担心一觉醒来服务挂了,第二天第一件是就是搞黑白名单进行拦截。
三降
1.机房降级
异地多活还记得前些年 “支付宝的光纤被挖断事件吗？” 没有异地多活架构抄的非常火。
还有就是服务间的调用,同机房的调用都是可以通过内网调用节省了部分网络开销。如果同机房服务一旦出现问题需要降级到本地其他机房甚至需要降级到异地其他机房。
2.服务降级
服务降级分为两大类 无损降级、有损降级。
当自身服务如果出现问题，例如使用到集群缓存中间件的是否考虑降级到本地缓存或从库。
核心服务避免不了使用一些缓存中间件那么就会存在,缓存一致性问题、数据库主从延迟问题。
那么这些问题解决方案业界大多数，非重要核心业务采用有损降级。提高服务的高可用低延时指标
经历:当时有一个服务提供一个核销码或券的功能，生产后进行立即查询。设计的方案可能也存在问题导致显示查询失败。这种属于实时场景优先考虑缓存一致问题。最终通过添加缓存延迟间隙时间控制,具体做法例如对一个订单号查询是进行阻塞 判断缓存延迟间隙时间是否为0，在进行查询。(高并发场景慎用)
3.降级预案
在一些特定场景下降级预案是必不可少的，有自动降级那么就有手动降级。
例如那些情况需要进行容器熔断、挂维护页等场景。
这种操作能让特殊场景下公司损失最小，保护核心功能正常运行。
大家觉得还不错的帮忙点个赞呗！
