最近在研究阿里的一些中间件，最近看到了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。但正是我们想要的了。