关于后端:Sentinel集群限流原理及TokenServer使用注意事项

应用 Sentinel 集群限流的，如果应用嵌入模式，在异地多活专线抖动状况下会呈现服务调用超时的状况，本文从限流概念和集群限流的实现形式登程整顿了该知识点，特地是网络抖动状况下，对服务造成影响状况进行具体阐明。

Sentinel 是一个系统性的高可用保障工具，提供了限流、降级、熔断等一系列的能力，基于这些能力做了语意化概念形象，这些概念对于了解实现机制特地有帮忙，所以这里也复述一下。

对于流量管制，有个一个模型：

流量管制有以下几个角度:

资源的调用关系，例如资源的调用链路，资源和资源之间的关系；
运行指标，例如 QPS、线程池、零碎负载等；
管制的成果，例如间接限流、冷启动、排队等。

Sentinel 的设计理念是让您自由选择管制的角度，并进行灵便组合，从而达到想要的成果。

那么，集群限流只是管制限流外面的一个属性，在单机限流的根底上进行增强，对于须要准确管制 qps 阈值的场景特地实用。

言归正传，Sentinel 的集群限流也没那么神秘，外围设计就是采纳一个中心化的 Token Server 来调配令牌来履行，每次申请都会通过实例的 Token Client 申请 Token Server 获取 token 并调用。如下图所示：

留神这里 Client 和 Server 是通过 tcp 长连贯的形式通信的，须要有 reconnect 的机制，比方这里 Client 连贯不上 Server，会期待 n * 2000ms 的形式始终尝试连贯。

Sentinel 集群限流服务端有两种启动形式：

嵌入模式（Embedded）适宜利用级别的限流，部署简略，但对利用性能有影响；
独立模式（Alone）适宜全局限流，须要独立部署。

假如咱们心愿给某个用户限度调用某个 API 的总 QPS 为 50，但机器数可能很多（比方有 100 台）。这时候咱们很天然地就想到，找一个 server 来专门来统计总的调用量，其它的实例都与这台 server 通信来判断是否能够调用。

假如一个服务访问量呈锯齿状，开启了弹性伸缩，机器数目不通明，那么这时候通过预估单实例 qps * 机器数的形式计算就会不精确。

这种场景比拟非凡，个别业务上不会遇到，不做展开讨论。

在生产实践配置集群限流过程中，如果遇到 TokenClient 和 TokenServer 网络抖动的状况下，会呈现什么问题呢？状况一：网络问题；状况二：TokenServer 外部异样；咱们先看状况一。

假如是网络问题，那么不必去关注 TokenServer 返回的 TokenResult 具体信息了，只须要看下对超时的判断逻辑了。

private static boolean passClusterCheck(FlowRule rule, Context context, DefaultNode node, int acquireCount,
                                        boolean prioritized) {
    try {TokenService clusterService = pickClusterService();
        if (clusterService == null) {return fallbackToLocalOrPass(rule, context, node, acquireCount, prioritized);
        }
        long flowId = rule.getClusterConfig().getFlowId();
        TokenResult result = clusterService.requestToken(flowId, acquireCount, prioritized);
        return applyTokenResult(result, rule, context, node, acquireCount, prioritized);
    } catch (Throwable ex) {RecordLog.warn("[FlowRuleChecker] Request cluster token unexpected failed", ex);
    }
    // 如果 failback 不可用间接 paass
    return fallbackToLocalOrPass(rule, context, node, acquireCount, prioritized);
}

private static boolean applyTokenResult(/*@NonNull*/ TokenResult result, FlowRule rule, Context context,
                                                         DefaultNode node,
                                                         int acquireCount, boolean prioritized) {switch (result.getStatus()) {
            case TokenResultStatus.OK:
                return true;
            case TokenResultStatus.SHOULD_WAIT:
                // 没有达到采样数量，期待 1000/SampleCount
                try {Thread.sleep(result.getWaitInMs());
                } catch (InterruptedException e) {e.printStackTrace();
                }
                return true;
            case TokenResultStatus.NO_RULE_EXISTS:
            case TokenResultStatus.BAD_REQUEST:
            case TokenResultStatus.FAIL:
            case TokenResultStatus.TOO_MANY_REQUEST:
                return fallbackToLocalOrPass(rule, context, node, acquireCount, prioritized);
            case TokenResultStatus.BLOCKED:
            default:
                return false;
        }
    }

private static boolean fallbackToLocalOrPass(FlowRule rule, Context context, DefaultNode node, int acquireCount,
                                             boolean prioritized) {if (rule.getClusterConfig().isFallbackToLocalWhenFail()) {return passLocalCheck(rule, context, node, acquireCount, prioritized);
    } else {
        // 不是配置了降级到本地限流，就间接 pass
        return true;
    }
}

public TokenResult requestToken(Long flowId, int acquireCount, boolean prioritized) {if (notValidRequest(flowId, acquireCount)) {return badRequest();
    }
    FlowRequestData data = new FlowRequestData().setCount(acquireCount)
        .setFlowId(flowId).setPriority(prioritized);
    ClusterRequest<FlowRequestData> request = new ClusterRequest<>(ClusterConstants.MSG_TYPE_FLOW, data);
    try {TokenResult result = sendTokenRequest(request);
        logForResult(result);
        return result;
    } catch (Exception ex) {
        // 异常情况下会间接返回 TokenResultStatus.FAIL
        ClusterClientStatLogUtil.log(ex.getMessage());
        return new TokenResult(TokenResultStatus.FAIL);
    }
}

在 requestToken 超时失败后，会返回 TokenResultStatus.FAIL。咱们晓得默认 TokenServer 申请的超时工夫是 20ms，那么网络出问题，此处会阻塞 20ms，而后降级到单机限流规定限流，而且每次都会申请 TokenServer 拿 token。

如果网络连接断了的状况呢？

@Override
public ClusterResponse sendRequest(ClusterRequest request) throws Exception {
    // 如果连贯状态异样，则 TokenClient 端疾速返回异样
    if (!isReady()) {throw new SentinelClusterException(ClusterErrorMessages.CLIENT_NOT_READY);
    }
  ...
}
@Override
public boolean isReady() {return channel != null && clientHandler != null && clientHandler.hasStarted();
}

剖析能够看进去，第一种状况，如果网络异常情况，会间接返回异样，那么最外层还是会走到本机限流的逻辑，不会增加调用耗时。如果网络慢，则期待超时工夫达到后返回。

如果是第二种状况 TokenServer 返回不失常状态，当 TokenResultStatus.SHOULD_WAIT，则期待返回的工夫，当 TokenResultStatus.BLOCKED，间接返回 false，被限流，当 TokenResultStatus.TOO_MANY_REQUEST，也是降级到本机限流。

在集群限流的时候，如果是嵌入模式 TokenServer 切换的霎时不会造成拜访报错，如果拜访网络超时，然而 TokenClient 和 TokenServer 网络未中断，还是会期待拜访后果，所以集群 Server 拜访超时工夫肯定不要设置太长，比方设置成 3s，那么在网络抖动状况下，每个申请都会加上这个 3s，造成大量超时。

这里给出下，如何配置集群限流超时工夫：

ClusterClientConfig clusterClientConfig = new ClusterClientConfig();
clusterClientConfig.setRequestTimeout(20);
ClusterClientConfigManager.applyNewConfig(clusterClientConfig);

（本文作者：朱云辉）

本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者应用。非商业目标转载或应用本文内容，敬请注明“内容转载自哈啰技术团队”。

关于后端:Sentinel集群限流原理及TokenServer使用注意事项

集群限流原理

集群限流应用场景

场景一、qps 量小比机器数还少

场景二、机器弹性伸缩、数目变动频繁

场景三、机器配置不一样，不同实例须要依据整体 qps 和机器水位综合限流

集群限流可用性诊断

TokenServer 通信网络问题

FlowRuleChecker

DefaultClusterTokenClient

NettyTransportClient

总结