高并发环境下qps计算

最近在研究阿里的一些中间件，最近看到了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