客户端和 dashboard 交互
- sentinel-transport 三个子工程，common 是基础包和接口定义
- 若客户端要接入 dashboard，可以使用 netty-http 或 simple-http 中的一个。为何不直接使用 Netty，而要同时提供 http 选项？
因为你不一定使用 Java 来实现 dashboard，如果使用其他语言，使用 http 协议比较容易适配。
下面我们只介绍 http 的使用，首先，添加 simple-http 依赖：
<dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-transport-simple-http</artifactId> <version>1.6.3</version> </dependency>
然后在应用启动参数中添加 dashboard 服务器地址，同时可以指定当前应用的名称：
-Dcsp.sentinel.dashboard.server=127.0.0.1:8080 -Dproject.name=sentinel-learning
这个时候我们打开 dashboard 是看不到这个应用的，因为没有注册。
当我们在第一次使用 Sentinel 以后，Sentinel 会自动注册。
下面带大家看看过程是怎样的。首先，我们在使用 Sentinel 的时候会调用 SphU#entry：
这里使用了 Env 类，其实就是这个类做的事情：
进到 InitExecutor.doInit 方法：
这里使用 SPI 加载 InitFunc 的实现，加载了
- CommandCenterInitFunc 类
客户端启动的接口服务，提供给 dashboard 查询数据和规则设置使用 - HeartbeatSenderInitFunc 类
用于客户端主动发送心跳信息给 dashboard
HeartbeatSenderInitFunc#init
定时器，以一定的间隔不断发送心跳信息到 dashboard 应用
dashboard 有了这些信息，就可以对应用进行规则设置、到应用拉取数据用于页面展示等。
Sentinel 在客户端并未使用第三方 http 包，而是自己基于 JDK 的 Socket 和 ServerSocket 接口实现了简单的客户端和服务端，主要也是为了不增加依赖。
Sentinel 中秒级 QPS 的统计问题
Sentinel 统计了 分 和 秒 两个维度数据：
1、对于 分 来说，一轮是 60 秒，分为 60 个时间窗口，每个时间窗口是 1 秒
2、对于 秒 来说，一轮是 1 秒，分为 2 个时间窗口，每个时间窗口是 0.5 秒
如果我们用上面介绍的统计分维度的 BucketLeapArray 来统计秒维度数据可以吗？不行，因为会不准确。
设想一个场景，我们的一个资源，访问的 QPS 稳定是 10，假设请求是均匀分布的，在相对时间 0.0 - 1.0 秒区间，通过了 10 个请求，我们在 1.1 秒的时候，观察到的 QPS 可能只有 5，因为此时第一个时间窗口被重置了，只有第二个时间窗口有值。
所以，我们可以知道，如果用 BucketLeapArray 来实现，会有 0~50% 的数据误差，这肯定是不能接受的。
那能不能增加窗口的数量来降低误差到一个合理的范围内呢？这个大家可以思考一下，考虑一下它对于性能是否有较大的损失。
StatisticNode 源码，对于秒维度数据统计，Sentinel 使用下面的构造方法：
OccupiableBucketLeapArray 的 newEmptyBucket 和 resetWindowTo 这两个方法和 BucketLeapArray 有点不一样，也就是在重置的时候，它不是直接重置成 0。
这个类里面的 borrowArray 做了一些事情，它是 FutureBucketLeapArray 的实例，这个类和前面接触的 BucketLeapArray 差不多，但是加了一个 Future 单词。它和 BucketLeapArray 唯一的不同是，重写了下面这个方法：
若按照这种定义，在调用 values() 方法的时候，所有的 2 个窗口都是过期的，将得不到任何的值。可以判断，给这个数组添加值的时候，使用的时间应该不是当前时间，而是一个未来的时间点。
回到 OccupiableBucketLeapArray 类，重置使用了 borrowArray 的值：
当主线到达某个时间窗口的时候，如果发现当前时间窗口是过期的，会重置这个窗口
再看 borrowArray 中的值是怎么进来的。
我们很容易可以找到，只可能通过这里的 addWaiting 方法设置：
接下来，我们找这个方法被哪里调用了，只有 DefaultController 类中有调用。
这个类是流控中的 “快速失败” 规则控制器，我们简单看一下代码：
OccupiableBucketLeapArray
Occupiable 这里代表可以被预占的意思，结合上面 DefaultController 的源码，可以知道它原来是用来满足 prioritized 类型的资源的，我们可以认为这类请求有较高的优先级。如果 QPS 达到阈值，这类资源通常不能用快速失败返回， 而是让它去预占未来的 QPS 容量。
当然，令人失望的是，这里根本没有解开 QPS 是怎么准确计算的这个问题。
下面证明 Sentinel 的秒维度的 QPS 统计是不准确的
public static void main(String[] args) { // 下面几行代码设置了 QPS 阈值是 100 FlowRule rule = new FlowRule("test"); rule.setGrade(RuleConstant.FLOW_GRADE_QPS); rule.setCount(100); rule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); List<FlowRule> list = new ArrayList<>(); list.add(rule); FlowRuleManager.loadRules(list); // 先通过一个请求，让 clusterNode 先建立起来 try (Entry entry = SphU.entry("test")) { } catch (BlockException e) { } // 起一个线程一直打印 qps 数据 new Thread(new Runnable() { @Override public void run() { while (true) { System.out.println(ClusterBuilderSlot.getClusterNode("test").passQps()); } } }).start(); while (true) { try (Entry entry = SphU.entry("test")) { Thread.sleep(5); } catch (BlockException e) { // ignore } catch (InterruptedException e) { // ignore } } }
然后观察下输出，QPS 数据在 50~100 这个区间一直变化，印证秒级 QPS 统计极度不准确。
参考
