高并发环境下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）。但sentinel的模式则是若发现要创建新的bucket，则让一个线程去创建，别的线程则取出上一个bucket进行处理（牺牲了一点时刻准确度，但换来了性能的大量提示）。

longadd

具体到某一个bucket时，需要对当前的bucket的value进行增加，传统的思路就是再对这个bucket的value进行加锁，那么这个地方就又回阻塞了，那么有没有好的办法的。肯定有啦，看sentinel的思路吧，其实就是用到了netflix的hytrixRollingNumber的办法（https://github.com/Netflix/Hystrix）。具体一点就是Striped64。

数据 striping 就是把逻辑上连续的数据分为多个段，使这一序列的段存储在不同的物理设备上。通过把段分散到多个设备上可以增加访问并发性，从而提升总体的吞吐量。

在JDK 8中，已经添加到的 java.util.concurrent.atomic 下的 Striped64 了。




abstract class Striped64 extends Number {    static final int NCPU = Runtime.getRuntime().availableProcessors();     // 存放 Cell 的表。当不为空时大小是 2 的幂。    transient volatile Cell[] cells;     // base 值，在没有竞争时使用，也作为表初始化竞争时的一个后备。    transient volatile long base;     // 自旋锁，在 resizing 和/或 创建Cell时使用。    transient volatile int cellsBusy;}




@sun.misc.Contended static final class Cell {     volatile long value;     Cell(long x) { value = x; }     final boolean cas(long cmp, long val) {          return UNSAFE.compareAndSwapLong(this, valueOffset, cmp, val);     }     // Unsafe mechanics     private static final sun.misc.Unsafe UNSAFE;     private static final long valueOffset;     static {          try {               UNSAFE = sun.misc.Unsafe.getUnsafe();               Class<?> ak = Cell.class;               valueOffset = UNSAFE.objectFieldOffset                    (ak.getDeclaredField("value"));          } catch (Exception e) {               throw new Error(e);          }     }}

看上面的注释应该就能看懂了吧，思路就是把锁的粒度变小，刚好这种思路是非常适合处理qps的。当然真实的value就是Striped64.value + Cell[0-n].value之和的，所以这种设计思路可以达到写基本是O(1)的，读会耗电cpu。但正是我们想要的了。