---

提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档

---

一. 服务雪崩

多个微服务之间调用时，比如A调用B和C，B和C又调用其他的服务，结果这中间可能某个环节出现调用失败的情况，很多时候，这些异常情况会导致CPU被立刻打满，进而蔓延至整个微服务，所以就需要Sentinel来对其进行服务降级，避免级联故障，提高分布式系统的弹性；

二. 断路器

服务降级到底是如何实现的呢？答：断路器； 断路器是一种思想，豪猪哥 Hystrix、Sentinel就是对断路器的两种实现，其实它们原理都一样，只不过Sentinel是后出的，肯定它实现的更好；

解释一下断路器：当分布式系统中，某个微服务发生故障时，断路器会向调用方返回一个符合预期的，可处理的备选响应（fallback），而不是长时间的等待或者抛出调用方无法处理的异常，从而避免了故障在分布式系统中的蔓延；

三. Sentinel的下载和安装

Windows下安装

docker安装

Sentinel仪表盘的端口默认是8080，还有一个Sentinel客户端的端口号默认是8719；

四.初始化监控

1. 导入依赖

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

这里除了要sentinel的依赖，还要导入nacos的依赖，因为一般sentinel都是配合nacos使用的，sentinel要监控nacos注册中心下的服务；

2. 编写yml

server:port: 8401
spring:application:name: bbga-accountcloud:nacos:discovery:server-addr: 192.168.11.10:8848sentinel:transport:dashboard: localhost:8080 # 这里指定sentinel仪表盘的端口port: 8719 # 要在这里指定sentinel客户端的默认端口
management:endpoints:web:exposure:include: '*'  # 这个配置是管理端口的，exposure是暴露的意思，include: '*' 表示暴露所有端口

注意：
1）sentinel客户端的端口默认是8719，你需要通过port参数进行指定，假如你指定成了8719，他会自动去判断8719是否被占用，如果被占用就自动加1，然后再测试下一个端口被占用，直到找到一个没被占用的端口作为sentinel客户端的端口；
2）这里为什么要暴露端口？
因为这里有sentinel仪表盘了，自然会涉及到端口暴露的问题；

3. 启动类上添加@EnableDiscoveryClient注解

@SpringBootApplication
@EnableDiscoveryClient
public class AccountApplicationn {public static void main(String[] args) {SpringApplication.run(AccountApplicationn.class, args);}
}

4. 进行测试

我们新建一个Account模块，对其进行以上的配置后，再为其编写一个Controller进行测试，看看到底Sentinel的仪表盘到底能否监控到这个模块；

@RestController
public class TestController {@GetMapping("test")public String test(){return "test";}
}

Sentinel的懒加载机制：

当你的服务启动好后，Sentinel的仪表盘上并不会like监控到这个服务的信息，因为Sentinel是采用的懒加载机制，所以我们需要先访问这个服务的接口，Sentinel才能加载到对这个服务的监控；

继续测试

1）我们再访问一下test接口

2）访问完之后打开Sentinel控制台，我们就能发现首页的左边多了关于我们这个account的信息，bbga-account是我取的application.name

五. Sentinel的实时监控功能：

点击实时监控，如果你的服务没有访问的话，就是下面这种状态：

然后我们现在疯狂的访问test接口，再查看Sentinel就能看到图表有了明显的变化：我们能看到在15:28:26时通过了6次QPS，拒绝了0次，QPS，QPS是每秒访问率的意思，意思就是在15:28:26这一秒内test接口被访问了6次，6次都通过，一次都没拒绝；

六. Sentinel的流控规则

在Sentinel中，可以新增流量控制规则，什么是流控规则？
看下面：

1）Sentinel中左边菜单栏的簇点链路，流控规则模块都可以添加流控规则，我们这里以簇点链路模块为例：

① 我们一般选择右上角的列表视图，树状视图看起来并不清晰；
② 我们能看到列表中有一个接口/test，这是我们刚才测试过的接口，被sentinel自动加到了簇点链路列表中，但是这个接口此时只是一个白板，根本没有对其添加流量控制规则；
③ 所以我们点击右边的 +流控 就能对 /test 接口添加流控规则；

④ 流控规则解释：

资源名：接口地址；

针对来源：sentinel的流控可以针对请求来源进行流控，默认是default—就是不针对来源进行流控，这里我们先采取default的模式；

阈值类型：阈值分为QPS和线程数，QPS是指你这个接口每秒钟被访问达到了多少次就进行限流，线程数指：你这个接口同时被多少个线程访问就限流，你可以任选一个模式，单击阈值：这里就填具体的值了，比如你选的是QPS，那么你这里填的值就代表每秒内这个接口最多能被访问多少次；

是否集群：我们这里演示的是单机，所以不选择集群，后面肯定要集群的

流控模式、流控效果： 流控模式跟流控效果就是高级的流控规则了，如果你不选的话，默认流控模式是直接，流控效果是快速失败；

直接流控模式： 这个模式的意思是：一旦达到QPS或者线程数达到阈值，Sentinel就会拒绝请求，并返回一个失败的页面给前端，失败页面如下：

我们需要思考的是：我们该如何把这个页面换成我们自己想要的页面，因为实际生产中肯定不能使用这个页面作为提示
2）线程数直接失败案例：

对阈值类型中的线程数类型作一下解释：要理解线程阈值类型，你要把添加规则的这个接口看成是一个银行柜台，假如你的线程阈值设置成了5，那么这个银行柜台的坐位就是5个，只有这5个座位中有空位的时候，其他人才能进去，就好比：你进来了五个请求，请求你的\test接口，这五个请求链路都还没有走完，那么你第6个请求就会被Sentinel阻止，也会提示Blocked by Sentinel页面，只有等前面5个请求的某个线程走完了一次链路，你第六个才能进去，这就是线程阈值类型；
3）流控模式：关联 >>> 当关联的资源达到阈值时，就限流自己

举个例子：我有一个支付服务，和一个下单服务，我用Sentinel对下单服务添加了限流规则，将支付服务与下单服务进行了关联；
当支付服务出现问题，或者说处理不过来，达到了预先设定的阈值时，我下单服务就限制自己，因为我都要支付不过来了，你还要给我下单，这就是添乱；关联流控模式的好处就是：防止故障蔓延；

举例看下图：我为testA这个资源绑定了关联流控模式的规则，同时将testB作为testA的关联资源，意思就是：当testB达到每秒QPS1时，testA就会直接拒绝后面的请求，返回sentinel限流页面； 假如testB之后每秒QPS又降到1以下了，testB就会恢复服务，此时你再访问A就又可以访问了； 这里需要注意的是：关联流控模式中，设定的阈值，实际上是对testB的阈值，而不是对testA的

4）流控模式：链路

还记得我们刚才讲的流控规则中的针对来源吗，我们上面填的是默认的default，针对来源：是针对微服务的来源，粒度比较大；但是链路流控模式针对的是接口，它粒度更细；所以链路流控模式跟针对来源很像，只不过一个是针对微服务级别，一个是针对接口级别；

六. Sentinel的熔断降级

除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一，由于调用关系的复杂性，如果调用链路中的某个资源出现了不稳定，最终会导致请求发生堆积，请求的响应时间变长，那么调用该服务的方法的响应时间也会变长，操作系统层面上线程造成堆积，最终可能会耗尽业务自身的线程池，服务本身也变得不可用；

Sentinel熔断策略一: 慢调用比例

选择 以慢调用比例作为阈值：
①你需要设置最大RT(最大RT就是请求的最大响应时间)，超过这个响应时间的都被Sentinel看做是慢调用；
②统计时长：默认是一秒，这个要配合比例阈值使用，你往下看就知道了；
③你还需要设置比例阈值：当统计时长内 >>> 默认1秒，也就是Sentinel每一秒钟进行一次统计，这一秒内，如果请求数目达到你设置的最小请求数，并且慢调用的比例超过了你设定的比例阈值，则接下来的熔断时长内，请求会被自动熔断；
④熔断时长：资源进入熔断状态后，并不是一直处于熔断，只是熔断一段时间，等这个时间过了，熔断器会转变为探测恢复状态；如果接下来的一个请求的响应时间小于你设置的最大RT，那么熔断器就会关闭，结束熔断，如果还是大于最大RT，那就继续熔断；

Sentinel熔断策略二: 异常比例

异常比例策略：这个策略跟上面的慢调用比例很像，只不过慢调用比例是针对于响应时间来说的，而异常比例是针对本次请求中是否发生异常来说的，比如NullPointException等等，一旦发生异常本次请求就会被标记为异常请求，且比例如果达到你设定的阈值，也会触发熔断，熔断时长过后，也会进入半开状态；
注意：Sentinel本身的BlockException是不会被算作异常的，并且如果本次请求中，你的异常被捕获处理掉了，也不会被算作异常；

Sentinel熔断策略三: 异常数

异常数策略：这个策略也差不多，只不过上面是针对异常比例，这里是针对单位时间内发生的异常请求数目；

七. Sentinel的热点规则

热点规则：其实就是更加细粒度的限流规则，可以对请求中的某个参数做限制，你要使用热点规则，就必须用到@SentinelResource注解

1、@SentinelResource注解

1）value：代表资源名称，必须配置
2）blockHandler：

2、举例：

1. 比如我现在发送了一个请求：localhost:8401/testHotKey，这个请求中需要传3个参数，hot1，hot2，hot13，reuired=false是非必要参数的意思；
   @SentinelResource(value = “testHotKey”)表示对testHotKey这个资源做热点规则限制，testHotKey就是接口名；
   
2. 添加热点规则
   ①资源名这里就是填方法名testHotKey而不是填接口地址名 /testHotKey，这里跟前面配置规则不一样，要注意了；
   ②参数索引：这里填0，意思就是你要对testHotKey方法中的第0号索引下的参数做热点限制，也就是对hot1做限制，而不是对hot2，hot13做限制；
   ③统计窗口时长：
   这样做的效果就是：当你传过来的参数是hot1，并且QPS达到了1之后，就会该资源testHotKey做限流，但如果你传过来的是hot2，hot13，那么就不会对该资源做限流；
   
   并且触发热点限流后，并不是原先的那种Blocked by Sentinel页面，而是直接报500，我们后续要解决这个问题：
   

3、在哪里添加热点规则

首先我们要清楚资源跟接口的区别，在Sentinel中接口是前面带斜杠/的，不带斜杠的是资源；也可以说@SentinelResource注解中value属性值testHotKey是资源，@GetMapping中标注的/testHotKey是接口；

你可以点击簇点链路 >>> 找到/testHotKey接口 >>> 由于我们代码中用@SentinelResource的value属性指定了资源名testHotKey，那么你可以看到/testHotKey接口下有一个testHotKey资源 >>> 你再点击右边的+热点，你就可以为该资源添加热点规则

4、解决热点规则限流页面直接显示500的问题

4.1. 在上面的学习中，我们发现，热线规则一旦限流，就会直接显示500，这个页面非常丑陋，我们并不想要这个界面，现在就来解决它：

我们需要用到@SentinelResource注解中的blockHandler属性，我们可以看到这个属性的值是String类型，要传进去的是方法名，也就是说：你可以专门写一个方法，来解决这个500错误页面问题，然后把方法名传给blockHandler属性；

4.2、 解决热点规则500报错的案例：

我给@SentinelResource注解添加了blockHandler属性，在下面写了一个handlerHotKey方法，注意这个方法的方法签名必须跟你@SentinelResource标注的资源的方法签名完全一致，同时要在最后面加上BlockException参数，然后再把方法名传入blockHandler；
相当于这个方法就是当该资源被限流时的兜底处理方法，你可以在里面写自己的逻辑，我这里只是简单的返回了一个字符串给前端；

特别注意：blockHandler是处理Sentinel控制台的异常，假如你的资源testHotKey中本身就有其他异常，如RuntimeException，你指定的handlerHotKey是处理不了的；因为handlerHotKey只能处理BlockException，这个异常就是Sentinel控制台的异常，当Sentinel限流某资源时就会抛出该异常；

5、热点规则高级部分

我们刚才设置的热点规则，是针对于请求中某个参数进行流控，那高级部分能达到什么效果呢？
我对参数hot1做热点流控，单击阈值为1，hot1为String类型，假如我想当hot1为5个字符串时，我让它的阈值变为200，其他的值阈值还是为1，那么你就可以使用热点规则的高级部分：
参数类型：要选择对应的参数类型，假如你hot1的参数类型为String，那么你这里的参数类型就要选择String，目前Sentinel只支持选择基本数据类型与String；
参数值：这个参数值就是上面举例中的5，5就是那个例外的参数值；
限流阈值：就是上面举例中的200阈值，也就是对5这个值的阈值； 注意：就算你5是字符串，你也不用加上双引号，Sentinel会自己帮你加；

八 .Sentinel的系统规则

个人目前感觉比较鸡肋

九. @SentinelResource自定义限流逻辑

1. 关于@SentinelResource在普通流控上的注意点：

上面我们在热点规则中使用了@SentinelResource来标注了资源名称，同时使用blockHandler属性指定了解决限流的方法；其实@SentinelResource还可以用在普通的流控规则上，blockHandler也可以可以对普通的流控起作用；

2. @SentinelResource URL限流

@SentinelResource也可以针对URL进行限流，但是不使用blockHandler属性，只使用value属性，此时就是对URL进行限流

这种形式下，由于你没有用blockHandler指定一个处理限流异常的方法，Sentinel会调用默认的限流异常处理方法，那这个默认的限流异常处理方法是什么呢？其实我们前面见过，就是下面这个页面；

3.自定义限流逻辑

其实我们在使用@SentinelResource注解的blockHandler方法来解决限流异常时，会出现一些不好的点：
① 每一个业务接口都添加一个限流处理方法，代码会愈加臃肿
② 自定义处理方法和业务耦合在一个类中
③ 无法实现统一全局处理

针对上面的问题：@SentinelResource提供了另一个属性blockHandlerClass来解决它，

第一步： 创建一个自定义的类，这个类专门用来写你自定义的限流处理逻辑（注意：①这个类里面的限流处理方法必须都是Static修饰，否则Sentinel无法解析；②异常处理方法要跟资源方法的方法签名保持一致，同时在最后面加上BlockException参数）

比如我现在就在这个类里写了两个方法，handlerException1，handlerException2

第二步：在对应的资源上，添加blockHandlerClass属性，用这个属性指定我们刚才创建好的类为专门的限流异常处理类，同时用blockHandler属性来指定到底使用这个类中哪一个方法作为本资源的限流处理方法；

第三步：给你的资源在Sentinel上添加限流规则就行了

十. Sentinel熔断环境的搭建

十一. @SentinelResource的fallback属性

Sentinel把Controller中的一个个接口称为资源，通过前面的学习，我们学到了如何优雅的处理Sentinel限流导致的异常，但是如果我的接口里本身就有代码导致的异常，比如空指针，RuntimeException等等任何我没预计到的异常，万一出现这些java本身的异常，那么用户在访问时就会直接出现下面这个异常页面：

我们肯定不想后台在出现异常时给前台用户报这个错，所以Sentinel就在@SentinelResource中提供了一个fallback属性，专门用来处理java本身的异常，其实在我们平时的开发中，还有一种处理方式也是解决这种问题的：就是全局异常处理；

1. fallback属性的用法

跟blockHandler属性的用法基本极其相似，fallback属性的值也是填对应异常处理方法的方法名；同样要保持异常处理方法的方法签名跟原资源保持一致，同样要多一个参数，只不过这个参数不再是BlockException，而是Trhowable，具体用法如下图所示：

2. fallbackClass属性

跟blockHandler一样，fallback也有对应的fallbackClass，用法跟blockHandlerClass极其相似，所以这里不再赘述；

3. @SentinelResource的exceptionsToIngore属性

用于指定哪些异常被排除掉，不会计入异常统计中，也不会计入fallback逻辑中（就不会执行fallbackHandler方法），而是会原样抛出；
exceptionsToIngore的值是一个数组类型，因为你可以填多个异常类型进去，表示排除多个异常类型；

十二. Sentinel规则持久化到Nacos

如果你将你的应用重启了，就会导致你Sentinel中配置的各种规则全部消失，所以需要对规则进行持久化，你可以持久化到数据库，文件，甚至Redis都行，但我们最常用的就是持久化到Nacos，Nacos本身也是有持久化的；

第一步： 引入依赖

你对某个资源进行了规则配置，你要进行规则持久化到nacos的话，你首先需要引入下面这个依赖，并且是将依赖引入到这个资源对应的服务中；并且你的Sentinel是什么版本，那么这个依赖你就要引入什么版本；

<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

第二步：yml配置

spring:cloud:sentinel:transport:dashboard: localhost:8080port: 8719datasource:nacos:nacos:serverAddr: localhost:8848 #指定nacos的地址gruopId: devdataId: order-sentinel.jsonruleType: flow #表示你本次Sentinel规则的类型，flow表示限流规则，而不是熔断规则等；

第三步：在nacos中新建order-sentinel.json配置文件

添加配置文件时，格式要选成JSON格式：
对下面JSON配置内容进行解释：
resource：资源名称（就是你@SentinelResource中的value属性的值）
limitApp：来源应用的名称，也就是你这个资源是属于哪个微服务
grade：阈值类型，0表示线程数，1表示QPS
count：表示单机阈值的值
strategy：表示流控模式，0表示直接，1表示关联，2表示链路
controlBehavior：表示流控效果，0表示快速失败，1表示wram up 预热，2表示排队等待
clusterMode：表示是否集群，值为true或false

并且注意：这个json是一个数组，表示你可以配置多个规则进去

等到上面这些都配置好后，你的服务重启，等你去访问某个资源时，Sentinel就会去读取nacos中的order-sentinel.json配置，就会把之前的规则读取出来；

Sentinel规则持久化到nacos配置文件中存在的问题：

比如我的Sentinel已经从nacos中读取了规则，比如将test1这个资源的规则已经读出来了，如下图：

但是如果我们此时通过Sentinel的编辑功能来修改了流控规则，比如我把这条流控规则中的单机阈值从2改成了1，这时候就有一个小问题：nacos中的配置并不会因此修改，你点开nacos的order-sentinel.json，会发现count的值还是2；所以这是一个值得注意的地方；

十三、Sentinle与gateway整合

在前面的学习中，我们都是在Sentinel中直接对某个资源进行流控，熔断等等，相当于你这个Sentinel是直接跟某个微服务打交道，但实际在微服务架构中，各个服务都不会直接暴露出来，而是由网关来统一接收请求，所以这个时候你的Sentinel还对各个服务中的资源做流控显然就不合适了，你必须得对网关限流；

Sentinel提供了对网关限流的支持，如gateway，zuul等网关都是支持与Sentinel整合的，我们这里讲Sentinel如何整合gateway；

整合第一步：在网关服务中引入依赖

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency><dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-spring-cloud-gateway-adapter</artifactId>
</dependency><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId>
</dependency>

yml文件不用变，你还是只需要跟往常一样配置好sentinel跟gateway的内容，就跟前面讲的保持一致即可；

第二步：启动网关，然后再通过网关访问某一个服务（因为Sentinel是惰性加载）

然后我们就能看到Sentinel控制台中，就出现了我们的网关服务，并且仔细看，这个网关服务左边的菜单栏还跟我们之前的普通服务的菜单栏不一样；
在这里叫请求链路，而不是叫簇点链路，还多了一个API管理，其他都差不多

新增网关流控规则：

我们点到请求链路，再点右边的+流控，就可以新增网关流控规则，对里面的参数进行解释：
API类型：默认就是Route ID类型，如果是这种类型，就代表你要针对整个路由id进行限流，比如你把QPS阈值设置成了10，那么属于这个路由id的微服务中的所有接口在单位时间内加起来只能被访问10次，显然这并不合理，因为我们要限流，肯定不会针对整个微服务都统一限流，而是需要针对接口限流，这个时候就需要第二种API类型：API分组，但要用API分组这种类型，你必须先点击API管理创建API分组，请往下看
API名称：API名称其实就是你在yml中配置的路由id，路由id就是你在yml中配置的这个横杠 id

针对请求属性：
阈值类型：不解释
QPS阈值：不解释
间隔：表示当达到限流后，你指定时间内的所有请求都会被拒绝
流控方式：快速失败，匀速排队，之前就讲过
Burst size：burst是激增的意思，表示在流量激增的情况下允许的最大流量，比如你把QPS阈值设置为了10，平时超过10就会限流，但是如果你把Burst size设置为了15，突然流量超出了，到达了13，此时也不会限流，除非是继续超过15了，才会被限流，相当于Burst size就是一个流量激增下的扩容的参数；

API管理

点击API管理后，右边有一个新增自定义API：
这里的API名称你可以随便填：
匹配模式有三种：精确，前缀，正则
1）

我们再回到刚才的新增流控规则，再选择API类型为 API分组，就能看到API名称处有了下拉框，下拉框中就是我们刚才建好的自定义API，里面的msb/**就是我们刚才建好的自定义api的API名称；

我们在建好流控规则后，我们再通过网关服务访问/msb/get接口就可以了，限流规则也会生效；
再梳理一下：我们刚才建好的API名称为msb/星星，其实这个名字是随便取的，你取个a也好，b也好都行，它只是一个名称，用于区别每个你创建好的API，我刚才选的匹配模式是精确匹配，匹配串是/msb/get，也就是说，我使用API分组类型对这个api创建好限流规则后，你的uri必须是 网关服务地址/msb/get，才能触发我建好的限流规则；

自定义API的匹配模式

API的匹配模式还有前缀匹配，正则匹配：
前缀匹配是针对你有参数的请求的，比如你的接口是/msb/login/{username}，你要对这个接口限流，你就可以用前缀匹配，在匹配传那里你就要填/msb/login/星星，星星表示匹配所有，只要前缀是/msb/login/；
注意：前面不能少斜杠，也就是/msb前面的斜杠必须要有，否则匹配不上

正则匹配：为什么要有正则匹配？
你看下面两个接口（前面有/msb），假如你要用前缀匹配的方式，那么你的匹配串就要写成/msb/login/星星，显然/msb/login/星星也包含了/msb/login/v1/{username}，这样就会导致这两个接口共用一套限流规则了，我下面那个接口就是想要一个单独的规则呢，该怎么办呢？我用精确匹配也不行，因为它有username参数，username是多变的，无法用精确匹配，这个时候就必须使用正则匹配

正则匹配写法：

我这里的解决方案是给/msb/login/{username}加正则匹配，给/msb/login/v1/{username}加前缀匹配/msb/login/v1/星星，这里的正则匹配时[0-9]{11}表示0-9中数出现11位就能匹配上；

【Sentinel】相关推荐

1. REDIS哨兵【Sentinel】模式+哨兵的核心知识点+redis哨兵主从切换的数据丢失问题+上一章铺垫的【异步复制数据丢失问题】+【集群脑裂】

   1.redis哨兵模式的前言: 一年一度的问题来了,为啥子要用redis的哨兵模式的呢? 简单粗暴的理解下子,顺带开个玩笑,没有理解好,还望不要见笑: 其实redis的哨兵模式,个人理解:只是说法搞大 ...

2. 【sentinel】Sentinel的介绍与使用

   前言 分布式系统的思考: 当服务访问量达到一定程度,流量扛不住的时候,该如何处理? 服务之间相互依赖,当服务A出现响应时间过长,影响到服务B的响应,进而产生连锁反应,直至影响整个依赖链上的所有服务,该 ...

3. 【sentinel】流控规则详解

   流量控制规则,简称流控规则,会对资源的流量进行限制.同一个资源可以对应多条限流规则.Sentinel会对该资源的所有限流规则依次遍历,直到有规则触发限流或者所有规则遍历完毕. 限流的直接表现是抛出Fl ...

4. Java之SpringCloud Alibaba【一】【Nacos一篇文章精通系列】

   Java之SpringCloud Alibaba[一][Nacos一篇文章精通系列] 一.微服务介绍 1.系统架构演变 1)单体应用架构 2)垂直应用架构 3)分布式 4)SOA架构 5)微服务框架 ...

5. 【Redis】使用Redis Sentinel实现Redis HA

   阅读目录 简单介绍 章节1:配置Sentinel.conf 章节2:启动Redis Sentinel 章节3:关闭master redis,测试failover 章节4:重新切换为最初的master ...

6. 【SpringCloud】Spring cloud Alibaba Sentinel 降级规则

   文章目录 1.概述 2.服务降级 2.1 RT 2.2 异常比例 2.3 异常数 1.概述 本章是接着上一章讲解:[SpringCloud]Spring cloud Alibaba Sentinel ...

7. 【Redis3】基于Redis sentinel的自动failover主从复制

   [Redis3]基于Redis sentinel的自动failover主从复制 在第二篇中使用2.8.17搭建了主从复制,但是它存在Master单点问题,为了解决这个问题,Redis从2.6开始引入s ...

8. 【Redis】缓存的三大问题及其解决方案

   作者:周二鸭 来源:https://www.cnblogs.com/jojop/p/14106671.html Redis经常用于系统中的缓存,这样可以解决目前IO设备无法满足互联网应用海量的读写请求 ...

9. 【转载】究竟啥才是互联网架构“高可用”

   一.什么是高可用 高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间. 假设系统一直能够提供服务,我们说系统的可用 ...

最新文章

1. 零基础如何学习软件测试
2. 聚类常见距离及python实现
3. 针对监控摄像机（海康、大华等）进行手动录像的录像文件播放器功能设计
4. vue 判断同一数组内的值是否一直_前端代码+后端API，值得一学的Vue高仿音乐播放器实战项目
5. C#环境下的钩子详解
6. c语言 单词变复数_关于C语言中的Complex（复数类型）和imaginary（虚数类型）
7. android适配规则（一）
8. PHP动态生成select标签
9. 网站维护不给提，问客服就说维护结束会给通知
10. Airflow 重跑dag中部分失败的任务
11. SpringBoot中Interceptor和Filter的使用
12. 软件测试面试题：和用户共同测试(UAT测试)的注意点有哪些?
13. 何凯明深度残差网络翻译
14. 服务启动类型：自动、自动(延时启动)、手动、禁用
15. 今日头条 巨量引擎 marketing api
16. asp.net消除锯齿的办法
17. 52.一文带你理解ARM程序的编译及执行过程
18. 自学MATLAB（四）：特征值与特征向量
19. Spring Cloud入门 -- Consul服务注册与发现（Hoxton.SR5版）
20. SVN搭建文件服务器

热门文章

1. 2018年STM32全国研讨会，演讲资料免费下载现场视频回看
2. 前瞻研究：电商领域人工智能发展与趋势
3. IDEA搭建Spring框架环境
4. maven三种打包方式详解
5. 如何下载DELL电脑系统恢复镜像并制作USB系统安装盘？
6. ESP32 通过Web图形控件调节PWM占空比输出
7. PyQt的动作（QAction）
8. 计算机科学与技术就业前景（二）
9. 感知机(Perceptron) Python实现
10. pythontkinter显示图片_python – 使用Tkinter显示图像