最近在研究阿里的一些中间件,最近看到了sentinel,由于和我们现在使用的统计-判断-预警-熔断有点类似,所以就深入了源码细看了一下,不看不要紧,一看吓一跳。我们现在的熔断的粒度是分钟级别的,没想到sentinel可以精细到任何级别,甚至是毫秒。我们姑且就按秒来说吧,一对比,就不是一个级别的了。
不说我们之前的架构了,还是说一下阿里sentinel使用的qps计算方法吧,给我印象最深刻的地方就是qps的计算模式了。
大家要知道,按qps为2000来算,每一毫秒就要有2个请求要处理,如果为了获取qps和并发环境下为了数据正确而加锁处理,那么会耗费很大的cpu资源。
而且若按curtime%1000作为key来统计请求数的话,假如当前时间为200ms,那么取得的qps则很有可能是总量的20%,那么肯定是不行的。
其实就是这么一个文件 https://github.com/Netflix/Hystrix/blob/master/hystrix-core/src/main/java/com/netflix/hystrix/util/HystrixRollingNumber.java
分片
首先sentinel采用的方法就是把一段时间分成若干片,如把1s分成10片,那么每片统计当前100ms内的数据,然后当前qps则为当前分片往前推10格,再求和,即为当前的qps。
那么问题来了,在分片的交接时刻,需要为新的分片创建对应的对象,若不加控制的话,直接加锁,会导致所有的线程等待(只有一个线程去创建当前bucket)。但s