weixin_51918722的博客

在固定的时间窗口内，可以允许固定数量的请求进入；超过数量就拒绝或者排队，等下一个时间段进入, 如下图时间窗长度划分为1秒单个时间窗的请求阈值为3上述存在一个问题, 假如9:18:04:333-9:18:05:000产生了2个请求, 9:18:05:000-9:18:05:333产生了3个请求, 那么也就是说9:18:04:333-9:18:05:333这一秒内产生5个请求, 正常来说这里已经超出了阈值。

熔断器分类和原理异常熔断器负责异常数/异常比例请求结束时统计异常数和请求总数, 判断是否达到阈值, 达到阈值更改熔断器状态RT熔断器:负责的是响应时间计算请求结束和请求开始的差值, 和阈值比较, 判断是否达到阈值, 达到阈值更改熔断器状态熔断器大体流程计数对比阈值熔断器验证状态流转OPEN: 熔断器打开, 系统进入熔断状态HALF_OPEN: 熔断器半开, 系统放行部分请求, 如果请求通过, 熔断器切回关闭状态, 如果请求出现异常, 熔断器切回打开, 继续熔断。

三个角色 1. 监听器 PropertyListener 2. 监听器管理者 SentinelProperty 3. 规则管理者 RuleManager

系统负载自适应规则的核心类是 SystemRuleManager,它负责管理系统负载自适应规则的加载、更新和监听。当系统负载自适应规则发生变化时,SystemRuleManager 通过观察者模式通知相应的 RulePropertyListener 进行更新

上述代码已经实例化了黑白名单监听器，并且已经将监听器交由 SentinelProperty 进行管理, 我们知道监听器监听的是规则, 那么还需要初始化规则。因为没必要, 看下述案例, 发现本质都是一样的, 换汤不换药罢了。, 将规则集合参数携带过去, 最终才能正常进入 for 循环遍历规则集合，将其组装成 Map 结构。监听器来感知黑白名单规则的变化, 将此监听器放入。方法就会进行规则的初始化, 具体的方法实现如下。进行规则初始化是不会成功的, 所以这里又调用。之后，我们会再执行一条初始化规则的代码.

规则通用的三个字段, 设置抽象类实现Rule接口, 对下述字段复用规则id资源名称限制来源限制来源指的是诸如黑名单值、白名单值等, 也就是说限制哪些来源访问// 实现规则 Rule 接口// 规则id// 资源名称// 限制来源, 多个用逗号隔开, 比如黑名单规则, 限制userId是1和3的访问, 那么就写setLimitApp(1,3)@Override为什么limitApp不使用？其实两者都是可行的, 你可以使用逗号分隔, 也可以使用, 只要能满足需求即可。

之前的NodeSelectorSlot和ClusterBuilderSlot已经完成了对资源调用树的构建, 现在则是要对资源进行收集, 核心点就是这些资源数据是如何统计

首先初始化Builder，负责管控责任链整体，Sentinel要求Builder只能存在一个，而且是外部系统优先原则，因此，我们可以自己编写一个以接口为名称的SPI文件来替代默认的 DefaultSlotChainBuilder。然后通过Builder初始化完整的责任链，这里仍然是通过SPI机制进行初始化，因此也可以额外扩展，比如外部系统自定义一个Slot且插入到完整责任链当中，这里值得注意的是责任链是有顺序的，如果顺序没指定正确，则可能造成意想不到的效果。顺序可以通过@Spi注解的order属性。

限流：通过限制请求速率、并发数或者用户数量来控制系统的流量，防止系统因为流量过大而崩溃或无响应的情况发生。熔断：在系统出现故障或异常时将故障节点从系统中断开，从而保证系统的可用性。降级：在系统过载的情况下保证核心功能的可用性。熔断和限流的区别在于：熔断是针对故障节点的，将故障节点从系统中断开，而降级是针对整个系统的，系统在过载的情况下关闭一些非核心功能，仍能提供核心功能的可用性。资源: 资源是被 Sentinel 保护和管理的对象规则：用来定义资源应该遵循的约束条件资源和规则的关系。

其实笔者在写这块的时候, 参考了大量的博客, 但是那些博客实现了持久化是有缺陷的, sentinel-dashboard中操作缺失能同步到nacos, 但是这里的规则是有问题的, 无法使用的, 和我们理想中的效果大相径庭, 排查的思路大概如下。