高并发环境下qps计算

最新推荐文章于 2025-11-13 10:00:00 发布

原创最新推荐文章于 2025-11-13 10:00:00 发布 · 1.6w 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#qps #HystrixRollingNumber

design 专栏收录该内容

1 篇文章

订阅专栏

本文探讨了阿里Sentinel与Netflix Hystrix在高并发环境下如何计算QPS，重点介绍了Sentinel的分片策略，将时间分为若干片以降低锁的使用，提高性能。同时提到了LongAdder的使用，利用数据striping提升并发访问的吞吐量，避免传统加锁带来的性能瓶颈。

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