背景信息

Sentinel集群流控通常适⽤于以下场景：

1. 单机流量不均：由于负载不均衡等原因导致每台机器的流量不均，这时使⽤单机流控可能会出现没有达到请求 总量，某些机器就开始限流的情况。

2. 集群⼩流量流控：某些⾼可⽤防护场景下需要将服务调⽤QPS限制到很⼩的量，此时平均到每台机器的QPS可 能⼩于1，⽆法通过单机流控进⾏精确控制。例如希望限制总QPS为50，但节点数有100个。

3. 有业务含义的流量控制：例如限制某个API每个⽤户每分钟调⽤不超过10次。

Sentinel 集群限流服务端的两种启动方式

• 独立模式（Alone），即作为独立的 token server 进程启动，独立部署，隔离性好，但是需要额外的部署操作。独立模式适合作为 Global Rate Limiter 给集群提供流控服务。

• 嵌入模式（Embedded），即作为内置的 token server 与服务在同一进程中启动。在此模式下，集群中各个实例都是对等的，token server 和 client 可以随时进行转变，因此无需单独部署，灵活性比较好。但是隔离性不佳，需要限制 token server 的总 QPS，防止影响应用本身。嵌入模式适合某个应用集群内部的流控。

基于嵌入模式的高可用

嵌入模式隔离性不佳，本文不做演示

基于独立模式的高可用

Sentinel 社区版只支持单节点部署token-server，生产高可用需要自行实现leader 选举，自动故障转移 ，且toke-server 节点之间不支持数据同步。

leader选举

1. 在/leader 路径下同时创建临时顺序节点，如果创建的节点编号为最小，则成为leader 身份，如果创建的节点编号不是最小，则为比当前节点编号小1位的节点注册监听

2. 在/leader路径下创建若干临时节点存储sentinel集群流控配置，写入leader身份的token-server 的地址，和步骤1 处于同一会话

3. token-client监听sentinel 集群流控配置项节点的变化，拉取当前leader 身份的token-server 地址和流控规则，刷新到内存

故障转移

1. 节点宕机，zk会话结束，临时节点被自动删除

2. 感知到/_c_00000153 节点被删除，再次竞争leader,节点编号为当前最小，成为leade身份

3. 节点宕机，zk会话结束，sentinel集群流控配置项临时节点被自动删除，待选举成功后，在/leader路径下重新创建若干临时节点存储sentinel集群流控配置项，写入新的leader 身份的 token- server地址和流控规则

4. token-client监听sentinel 集群流控配置项节点，拉取当前leader 身份的token-server 地址和流控规则，刷新到内存

存在的问题

1. token-server选举期间集群流控退化为单机本地流控

2. token-server节点之间暂不支持数据同步，故障转移之后受保护资源的token计数丢失且处于流控状态的资源被放开