限流：系统只允许本身能够承受的流量进来，超出系统能够承受的流量丢弃或者直接决绝
系统把阈值之外的流量直接拒绝或者加入队列排队处理
主要从用户调用压力的角度考虑应对故障
服务端自己限制自己
别人调我，我怕我自己扛不住，把别人踢出去
熔断：服务端调用第三方api，我怕别人不行，我给自己做了个方案
防止别人把我拖垮
降级：功能优先级的角度考虑应对故障
限流方案：1.基于请求的限流访问总量单位时间阈值缺点：总量和阈值不好评估
解决方案：预估+压测+上线监测+动态调整（建议放缓存里，增加修改页面，暴露在内网）2.基于资源的限流内部资源问题：如何确定关键资源，如何确定资源的阈值解决方案：与基于请求的限流类似，预估+压测+上线监测+动态调整（建议放入配置文件或者缓存中，便于实时调整），可以利用池化技术来解决
比如数据库连接池等等
限流延伸排队：排队模块，服务模块，调度模块计算流量的方法：固定时间窗口算法：会有请求突刺的情况
滑动时间窗口算法：固定时间窗口分割成N小份漏桶算法：注意流出速度与服务器性能
如果流出速度过快，则相当于没有限流
如果流出速度过慢，则浪费了系统的性能
桶容量=流出速度最大等待时长
由于流出速率固定
没办法根据系统负载情况动态调整，但是可以应对突发大量请求的情况
可动态调整桶容量的大小
令牌桶算法：控制流入速度
不能应对突发大量请求的情况
可根据系统负载动态调整令牌桶大小
定时放令牌，请求来了先获取令牌，获取到了就接着进行业务处理
获取不到就等待或者拒绝
默认初始化令牌，请求来了先拿令牌，请求完了还令牌
动态调整令牌桶大小
节流：防抖 控制一段时间间隔内同一操作的次数，只处理最后一次