免费建立网站软件推广app的软文案例

父文章 异常导致级联雪崩的例子 - 不应该有立即重试._个人渣记录仅为自己搜索用的博客-CSDN博客

一个系统处于稳态临界点

  如果立即重试3次, 会导致流量瞬间增大, 哪怕后来系统10s内自愈了, 这个时候, 流量本质上增加了3倍. 如果rpc框架不是fastFail ( 超过 调用方失败timeout上限 )( 前提是网络io还没到瓶颈,即tcp连接还是能连上 ) , 因为做不到这点, 所以都是非fastFail的系统, 除了上游自己能控制的,例如锁等待还是fastFail , 那么就会让流量继续堆积, 哪怕后续稳定了 一直在处理重复的请求. 

rpc    fastFail的本质.

        1. fail是哪层?

           线程池满了, fail了, 有队列 ,那么对线程池满了这个fail,就不是fastFail. 放入队列是一种方式, 就变成了不fail. 但是这个就会引发重试导致的一直在处理重复的请求的问题, 故障恢复就比较慢.  

           如果把线程池设置的无限大, 导致切换非常频繁, cpu时间* 线程池数>3s了, 新的一个流量端过来,要等待3s才能执行上或者执行完, 再加上io,时间, 上游肯定又重试, 这样子3倍io流量还是维持. 所以单cpu线程池不能超过300, 因为cpu时间执行10毫秒是正常的. 现在需要统计cpu执行时间.  线程数 系统失败还是维持. 和fastFail无关了. 本质是3倍流量已经支持不住了 ,  但是很少支持不了3倍线程池, 更多的是限制线程池数. 这样新来的流量不需要叠加排队时间, cpu执行时间 + io时间.

   队列长度 * rpc平均执行时间 ( cpu耗时 + io耗时 ) <= 外部调用超时设置( 3s )  队列长度需要能够动态控制. 如果不能动态控制, 就不要实现队列长度.

  python的GIL锁 不一样, 类似于cpu的切换,   而不是单线程. cpu耗时 * 线程数量 < 3s   , 线程数量可以很多 ,但也不能无限多, 线程池满了之后需要fastFail

如果下游大面积失败，这种时候是不适合重试的，我们可以配置一个比如请求量超过100且失败率超过10%不重试的策略, (统计窗口是1s,3s,10s,30s,60s ,超过1分钟都没有超过100, 这种全量重试也无妨.), 这样在单机层面就可以避免很多不必要的重试。