4. sentinel和hystrix的区别
两者的原则是一致的, 都是当一个资源出现问题时, 让其快速失败, 不要波及到其它服务，但是在限制的手段上, 确采取了完全不一样的方法:
Hystrix 采用的是线程池隔离的方式, 优点是做到了资源之间的隔离, 缺点是增加了线程切换的成本。
Sentinel 采用的是通过并发线程的数量和响应时间来对资源做限制。
功能 | Sentinel | Hystrix |
隔离策略 | 信号量隔离 | 线程池隔离（默认并且是官方推荐）/信号量隔离 |
熔断策略 | 慢调用比例、异常比率、异常数 | 基于失败比率（网络超时也是失败） |
实时统计实现 | 滑动窗口（LeapArray） | 滑动窗口(基于RxJava) |
基于注解的支持 | 支持 | 支持 |
限流 | 基于QPS，支持基于调用关系的限流 （关联流控，链路流控） | 有限的支持 |
流量整形 | 支持预热模式、排队等待 | 不支持 |
系统自适应保护 | 支持 | 不支持 |
控制台 | 可配置规则、查看秒级监控、机器发现等 | 不完善 |
5. Sentinel对应流控模式有哪几种
sentinel共有三种流控模式，分别是：
直接：指定来源对于该资源的访问达到限流条件时，开启限流。
关联：当与该资源设置了关联的资源达到限流条件（来源+阈值类型+单机阈值）时，开启限流 [适合做应用让步]
链路：当从某个上游资源接口访问过来的流量达到限流条件时，开启限流。
6. 流控效果
快速失败（默认）:
直接失败，抛出异常，不做任何额外的处理，是最简单的效果。
算法：滑动窗口。
使用场景：这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位时。
Warm Up：
它从开始阈值到最大QPS阈值会有一个缓冲阶段，一开始的阈值是最大QPS阈值的 1/3，然后慢慢增长，直到最大阈值，适用于将突然增大的流量转换为缓步增长的场景。 冷加载因子: codeFactor 默认是3，即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值。
算法：令牌桶算法。
使用场景：在某些情况下，系统可能会突然遭受到大量的请求压力，例如广告投放、秒杀活动等场景。通过预热机制，可以提前逐渐增加系统的流量限制，以减轻系统在高峰期的压力。
排队等待：
让请求以均匀的速度通过，单机阈值为每秒通过数量，其余的排队等待； 它还会让设置一个超时时间，当请求超过超时间时间还未处理，则会被丢弃。
算法：漏斗算法
使用场景：这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。
注意点：匀速排队模式暂时不支持 QPS > 1000 的场景
8. 系统规则保护
系统保护规则是应用整体维度的，而不是资源维度的，并且仅对入口流量 (进入应用的流量) 生效。
Load（仅对 Linux/Unix-like 机器生效）：当系统 load1 超过阈值，且系统当前的并发线程数超过系统容量时才会触发系统保护。系统容量由系统的 maxQps * minRt 计算得出。设定参考值一般是 CPU cores * 2.5。
RT：当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
线程数：当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
入口 QPS：当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。
CPU使用率：当单台机器上所有入口流量的 CPU使用率达到阈值即触发系统保护。
发表评论