Sentinel的基本使用案例

最新推荐文章于 2023-12-23 01:25:18 发布
最新推荐文章于 2023-12-23 01:25:18 发布
阅读量647 收藏 1
点赞数
分类专栏： Spring 微服务 文章标签： sentinel java dubbo
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/delete_bug/article/details/127309995
版权

简介

https://github.com/alibaba/Sentinel 官⽹地址
https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D 中⽂⽂档
随着微服务的流⾏，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切⼊点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Sentinel 具有以下特征:

丰富的应⽤场景：Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填⾕、集群流量控制、实时熔断下游不可⽤应⽤等。
完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接⼊应⽤的单台机器秒级数据，甚⾄ 500 台以下规模的集群的汇总运⾏情况。
⼴泛的开源⽣态：Sentinel 提供开箱即⽤的与其它开源框架/库的整合模块，例如与 SpringCloud、Dubbo、gRPC 的整合。您只需要引⼊相应的依赖并进⾏简单的配置即可快速地接⼊Sentinel。
完善的 SPI 扩展点：Sentinel 提供简单易⽤、完善的 SPI 扩展接⼝。您可以通过实现扩展接⼝来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
在这里插入图片描述

安装

1）下载
https://github.com/alibaba/Sentinel/releases/download/1.8.1/sentinel-dashboard-1.8.1.jar 下载地址
2）启动

nohup java -jar sentinel-dashboard-1.8.1.jar > myout.file 2>&1 &

3）访问
http://localhost:8080，⽤户名密码都是sentinel

Windows 启动
在这里插入图片描述
在这里插入图片描述

案例：

pom.xml

<!-- 后续做Sentinel的持久化会⽤到的依赖 -->
 <dependency>
   <groupId>com.alibaba.csp</groupId>
   <artifactId>sentinel-datasource-nacos</artifactId>
 </dependency>
 <!-- sentinel -->
 <dependency>
   <groupId>com.alibaba.cloud</groupId>
   <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
 </dependency>

yml 配置：

spring:
 cloud:
   nacos:
     discovery:
       server-addr: localhost:8848
   sentinel:
     transport:
     #配置Sentinel dashboard地址
      dashboard: localhost:8080
    #默认8719端⼝，假如被占⽤会⾃动从8719开始依次+1扫描,直⾄找到未被占⽤的端⼝
      port: 8719

FlowLimitController

@RestController
@Slf4j
public class FlowLimitController
{
 @GetMapping("/testA")
 public String testA()
 {
 return "------testA";
 }
 @GetMapping("/testB")
 public String testB()
 {
 log.info(Thread.currentThread().getName()+"\t"+"...testB");
 return "------testB";
 }
}

sentinel采⽤懒加载⽅式，执⾏⼀次微服务调⽤，sentinel控制台即可监控到该微服务
设置好以后在这里插入图片描述
本地 启动Nacos，启动Sentinel

sentinel采⽤懒加载⽅式，执⾏⼀次微服务调⽤，sentinel控制台即可监控到该微服务
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

流量控制

介绍

在这里插入图片描述
流量控制（flow control），其原理是监控应⽤流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进⾏控制，以避免被瞬时的流量⾼峰冲垮，从⽽保障应⽤的⾼可⽤性。
**资源名：**唯⼀名称，默认请求路径
针对来源：Sentinel可以针对调⽤者进⾏限流，填写微服务名，默认default(不区分来源)
阈值类型：
QPS（每秒请求数量）：当调⽤改api的QPS达到阈值的时候，进⾏限流
线程数，当调⽤该api的线程数达到阈值的时候，进⾏限流
是否集群：不需要集群
流控模式
直接：api达到限流条件时，直接限流
关联：当关联的资源达到阈值时，限流⾃⼰
链路，只记录链路上的流量（指定资源从⼊⼝资源进来的流量，如果达到阈值，就进⾏限流）
流控效果：
快速失败：直接失败，抛出异常
Warm UP：根据codeFactor（冷加载因⼦,默认3)的值，从阈/codeFactor，经过预热时⻓，才达到设置的QPS阈值
排队等待：匀速排队，让请求以匀速的速度通过，阈值类型必须设置QPS，否则⽆效

功能对⽐

在这里插入图片描述

线程池隔离和信号量隔离区别

信号量模式
“信号量”在编程术语中使⽤单词semaphore，那什么是“信号量”？信号量就好⽐你家厨房⼊⼝架⼦上摆了三把锅：
如果你的孩⼦热奶拿⾛⼀把，你的⽼婆热汤拿⾛⼀把，你的妈妈做菜拿⾛⼀把，你想煮⾯条就没有锅了。当你看到这种情况，你就不会进⼊厨房了，也就说厨房按照“锅的数量”作为信号量，只能容纳三个⼈(线程)。
当你的⽼婆热完汤之后，把锅重新放回架⼦上，你就可以去获得⼀个锅，你就可以进⼊厨房了。所以说：当信号量总数为1的时候，也就是你家只有⼀把锅，此时信号量作⽤就等同于互斥锁。
在该模式下，接收请求和执⾏下游依赖在同⼀个线程内完成，不存在线程上下⽂切换所带来的性能开销，所以⼤部分场景应该选择信号量模式，但是在下⾯这种情况下，信号量模式并⾮是⼀个好的选择。

⽐如⼀个接⼝中依赖了3个下游：serviceA、serviceB、serviceC，且这3个服务返回的数据互相不依赖，这种情况下如果针对A、B、C的熔断降级使⽤信号量模式，那么接⼝耗时就等于请求A、B、C服务耗时的总和，⽆疑这不是好的⽅案。
　　另外，为了限制对下游依赖的并发调⽤量，可以配置Hystrix的
execution.isolation.semaphore.maxConcurrentRequests ，当并发请求数达到阈值时，请求线程可以快速失败，执⾏降级
　实现也很简单，⼀个简单的计数器，当请求进⼊熔断器时，执⾏ tryAcquire() ,计数器加1，结果⼤于阈值的话，就返回false，发⽣信号量拒绝事件，执⾏降级逻辑。当请求离开熔断器时，执⾏ release() ，计数器减1。
　hystrix中配置使⽤信号量模式

hystrix.command.default.execution.isolation.thread.strategy=SEMAPHORE

线程池隔离模式
在这里插入图片描述
在该模式下，⽤户请求会被提交到各⾃的线程池中执⾏，把执⾏每个下游服务的线程分离，从⽽达到资源隔离的作⽤。当线程池来不及处理并且请求队列塞满时，新进来的请求将快速失败，可以避免依赖问题扩散。
在application.yml中修改默认线程池⼤⼩

hystrix.threadpool.service-provider.coreSize=100

在信号量模式提到的问题，对所依赖的多个下游服务，通过线程池的异步执⾏，可以有效的提⾼接⼝性能。
　在这里插入图片描述

演示QPS案例
xx
测试每秒钟超过1此api请求，抛出Blocked by Sentinel (flow limiting)
阈值类型：线程数
并发数控制⽤于保护业务线程池不被慢调⽤耗尽。Sentinel 并发控制不负责创建和管理线程池，⽽是简单统计当前请求上下⽂的线程数⽬（正在执⾏的调⽤数⽬），如果超出阈值，新的请求会被⽴即拒绝，
效果类似于信号量隔离。并发数控制通常在调⽤端进⾏配置。
在这里插入图片描述

@GetMapping("/testA")
public String testA() throws InterruptedException {
 TimeUnit.MILLISECONDS.sleep(2000);
 return "------testA";
}

测试线程超出阈值，直接抛出Blocked by Sentinel (flow limiting)

*流控模式：直接
在这里插入图片描述
限流表现：当超过阀值，就会被降级，抛出异常Blocked by Sentinel (flow limiting)

流控模式：
关联：
当关联的资源达到阈值，就限流⾃⼰，也就是当与testA关联的testB达到阈值，就限流⾃⼰配置如下：
在这里插入图片描述
使⽤Postman请求/testB
在这里插入图片描述
效果：/testB达到访问阈值，/testA降级

流控效果–预热
Warm Up（ RuleConstant.CONTROL_BEHAVIOR_WARM_UP ）⽅式，即预热/冷启动⽅式。当系统⻓期处于低⽔位的情况下，当流量突然增加时，直接把系统拉升到⾼⽔位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在⼀定时间内逐渐增加到阈值上限，给冷系统⼀个预热的时间，避免冷系统被压垮
在这里插入图片描述
测试效果，开始阈值默认3，经过预热慢慢涨到10
warm :一段时间后QPS达不到10的话会又调整回3去，当访问量再次上去的时候，会再次调整预热
流控效果：匀速排队
匀速排队（ RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER ）⽅式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。
该⽅式的作⽤如下图所示：
在这里插入图片描述

这种⽅式主要⽤于处理间隔性突发的流量，例如消息队列。想象⼀下这样的场景，在某⼀秒有⼤量的请求到来，⽽接下来的⼏秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，
⽽不是在第⼀秒直接拒绝多余的请求。
注意：匀速排队模式暂时不⽀持 QPS > 1000 的场景。
在这里插入图片描述
在这里插入图片描述

熔断降级

1）概述
除了流量控制以外，对调⽤链路中不稳定的资源进⾏熔断降级也是保障⾼可⽤的重要措施之⼀。⼀个服务常常会调⽤别的模块，可能是另外的⼀个远程服务、数据库，或者第三⽅ API 等。例如，⽀付的时候，可能需要远程调⽤银联提供的 API；查询某个商品的价格，可能需要进⾏数据库查询。然⽽，这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况，请求的响应时间变⻓，那么调⽤服务的⽅法的响应时间也会变⻓，线程会产⽣堆积，最终可能耗尽业务⾃身的线程池，服务本身也变得不可⽤。
在这里插入图片描述
现代微服务架构都是分布式的，由⾮常多的服务组成。不同服务之间相互调⽤，组成复杂的调⽤链路。
以上的问题在链路调⽤中会产⽣放⼤的效果。复杂链路上的某⼀环不稳定，就可能会层层级联，最终导致整个链路都不可⽤。因此我们需要对不稳定的弱依赖服务调⽤进⾏熔断降级，暂时切断不稳定调⽤，避免局部不稳定因素导致整体的雪崩。熔断降级作为保护⾃身的⼿段，通常在客户端（调⽤端）进⾏配置。
2）熔断策略
Sentinel 提供以下⼏种熔断策略：
慢调⽤⽐例 ( SLOW_REQUEST_RATIO )：选择以慢调⽤⽐例作为阈值，需要设置允许的慢调⽤ RT（即最⼤的响应时间），请求的响应时间⼤于该值则统计为慢调⽤。当单位统计时⻓（ statIntervalMs ）内请求数⽬⼤于设置的最⼩请求数⽬，并且慢调⽤的⽐例⼤于阈值，则接下来的熔断时⻓内请求会⾃动被熔断。经过熔断时⻓后熔断器会进⼊探测恢复状态（HALF-OPEN 状态），若接下来的⼀个请求响应时间⼩于设置的慢调⽤ RT 则结束熔断，若⼤于设置的慢调⽤ RT 则会再次被熔断。
异常⽐例 ( ERROR_RATIO )：当单位统计时⻓（ statIntervalMs ）内请求数⽬⼤于设置的最⼩请求数⽬，并且异常的⽐例⼤于阈值，则接下来的熔断时⻓内请求会⾃动被熔断。经过熔断时⻓后熔断器会进⼊探测恢复状态（HALF-OPEN 状态），若接下来的⼀个请求成功完成（没有错误）则结
束熔断，否则会再次被熔断。异常⽐率的阈值范围是 [0.0, 1.0] ，代表 0% - 100%。
异常数 ( ERROR_COUNT )：当单位统计时⻓内的异常数⽬超过阈值之后会⾃动进⾏熔断。经过熔断时⻓后熔断器会进⼊探测恢复状态（HALF-OPEN 状态），若接下来的⼀个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。
3）演示

慢调用比例：
在这里插入图片描述

条件1 ：在1s内有5次以上请求，比如说10次请求
条件2： 8次请求RT超过0.2秒
效果：在接下来1秒内熔断

使⽤JMeter启动并发请求：
在这里插入图片描述
效果：/testD服务降级，抛出异常Blocked by Sentinel (flow limiting)，关闭JMeter，1秒后恢复
异常⽐例
配置如下：
在这里插入图片描述
使⽤JMeter启动并发请求
在这里插入图片描述
效果：/testD服务降级，抛出异常Blocked by Sentinel (flow limiting)，关闭JMeter，3秒后恢复
异常数
配置如下：
在这里插入图片描述
在这里插入图片描述
效果：/testD服务降级，抛出异常Blocked by Sentinel (flow limiting)，关闭JMeter，10秒后恢复

热点参数限流

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最⾼的 Top K 数据，并对其访问进⾏限制。⽐如：
商品 ID 为参数，统计⼀段时间内最常购买的商品 ID 并进⾏限制
⽤户 ID 为参数，针对⼀段时间内频繁访问的⽤户 ID 进⾏限制
热点参数限流会统计传⼊参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调⽤进⾏限流。热点参数限流可以看做是⼀种特殊的流量控制，仅对包含热点参数的资源调⽤⽣效。
在这里插入图片描述
Sentinel 利⽤ LRU 策略统计最近最常访问的热点参数，结合令牌桶算法来进⾏参数级别的流控。热点参数限流⽀持集群模式。
热点参数限流需要使⽤@SentinelResource注解，具体代码如下：

 @GetMapping("/testHotKey")
    @SentinelResource(value = "testHotKey", blockHandler = "deal_testHotKey")
    public String testHotKey(@RequestParam(value = "p1", required = false) String p1,
                             @RequestParam(value = "p2", required = false) String p2) {
        //int age = 10/0;
        return "------testHotKey";
    }
    public String deal_testHotKey(String p1, String p2, BlockException exception) {
        return "------deal_testHotKey,o(╥﹏╥)o"; //sentinel默认抛出 ParamFlowException
    }

注：@SentinelResource，功能类似@HystrixCommand
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

参数索引为0，默认就是P1

@SentinelResource详解

注意：注解⽅式埋点不⽀持 private ⽅法

@SentinelResource ⽤于定义资源，并提供可选的异常处理和 fallback 配置项。
@SentinelResource 注解包含以下属性：
value ：资源名称，必需项（不能为空）
entryType ：entry 类型，可选项（默认为 EntryType.OUT ）
blockHandler / blockHandlerClass : blockHandler 对应处理 BlockException 的函数名称，可选项。blockHandler 函数访问范围需要是 public ，返回类型需要与原⽅法相匹配，参数类型需要和原⽅法相匹配并且最后加⼀个额外的参数，类型为 BlockException 。blockHandler函数默认需要和原⽅法在同⼀个类中。若希望使⽤其他类的函数，则可以指定blockHandlerClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则⽆法解析。
fallback/fallbackClass：fallback 函数名称，可选项，⽤于在抛出异常的时候提供 fallback 处理逻辑。fallback 函数可以针对所有类型的异常（除了 exceptionsToIgnore ⾥⾯排除掉的异常类型）进⾏处理。fallback 函数签名和位置要求：

  • 返回值类型必须与原函数返回值类型⼀致；
  • ⽅法参数列表需要和原函数⼀致，或者可以额外多⼀个 Throwable 类型的参数⽤于接收对应的异常。
  • fallback 函数默认需要和原⽅法在同⼀个类中。若希望使⽤其他类的函数，则可以指定fallbackClass 为对应的类的 Class
    对象，注意对应的函数必需为 static 函数，否则⽆法解析。

defaultFallback （since 1.6.0）：默认的 fallback 函数名称，可选项，通常⽤于通⽤的fallback 逻辑（即可以⽤于很多服务或⽅法）。默认 fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore ⾥⾯排除掉的异常类型）进⾏处理。若同时配置了 fallback 和defaultFallback，则只有 fallback 会⽣效。defaultFallback 函数签名要求：
返回值类型必须与原函数返回值类型⼀致；
⽅法参数列表需要为空，或者可以额外多⼀个 Throwable 类型的参数⽤于接收对应的异常。
defaultFallback 函数默认需要和原⽅法在同⼀个类中。若希望使⽤其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则⽆法解析。
exceptionsToIgnore （since 1.6.0）：⽤于指定哪些异常被排除掉，不会计⼊异常统计中，也不会进⼊ fallback 逻辑中，⽽是会原样抛出。

服务熔断综合应⽤

Ribbon
在订单微服务中使⽤RestTemplate调⽤⽀付微服务，配置服务限流和降级

@GetMapping("/consumer/ribbon/{id}")
    @SentinelResource(value = "ribbon", fallback = "handlerFallback",
            blockHandler = "blockHandler", exceptionsToIgnore ={IllegalArgumentException.class} )
    public CommonResult consumerRibbon(@PathVariable("id") Long id) {
        CommonResult<Payment> result = restTemplate.getForObject(SERVICE_URL +"/paymentSQL/" + id, CommonResult.class);
        if (4 == id) {
            throw new IllegalArgumentException("id=4，抛出⾮法参数异常");
        } else if (result.getData() == null) {
            throw new NullPointerException("空指针异常,id不存在。。。");
        }
        return result;
    }
    public CommonResult handlerFallback(@PathVariable("id") Long id, Throwable  e) {
        Payment payment = new Payment(id, "业务异常。。。");
        return new CommonResult(444, "业务异常兜底⽅法 e=" + e.getMessage(), payment);
    }
    public CommonResult blockHandler(@PathVariable("id") Long id, BlockException e) {
        Payment payment = new Payment(id, "控制台违规异常。。。");
        return new CommonResult(445, "控制台违规异常 e=" + e.getMessage(),  payment);
    }

设置限流规则，或者关闭⽀付微服务，可以看到服务降级的效果
common.yaml配置

#对Feign的⽀持
feign:
 sentinel:
   enabled: true

设置限流规则，或者关闭⽀付微服务，可以看到服务降级的效果

blockHandler 处理控制台异常，配置的规则违规会进入到这个处理器。
后者处理业务异常

按照系统没有处理异常，报错如下：
在这里插入图片描述
加入Sentinel异常处理后，
访问id 为5的商品时，出现

在这里插入图片描述

当加上流控规则以后
在这里插入图片描述
在这里插入图片描述
可以看到已经做出了流控规则的响应。

如果不设置blockHandler，则默认会按照handlerFallback的方法执行异常返回

这里加上 忽略 非法参数异常的参数后，系统会按照默认的方法去报错，不进行降级处理
在这里插入图片描述

feign
当服务挂掉以后，默认抛异常
在这里插入图片描述
当启用了feign的服务降级以后，
服务挂掉以后，再去调用会显示
在这里插入图片描述

持久化

⽬前的sentinel 当重启以后，数据都会丢失，和 nacos 类似原理。需要持久化。它可以被持久化到 nacos 的数据库中。
1）pom依赖：

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

2）yml配置：

spring:
 cloud:
   sentinel:
     datasource:
 ds1: 
 nacos:
   server-addr: localhost:8848
   dataId: ${spring.application.name}
   group: DEFAULT_GROUP
   data-type: json
   rule-type: flow

3）去nacos上创建⼀个dataid ,名字和yml配置的⼀致，json格式，内容如下：

[
 {
 "resource": "/testA",
 "limitApp": "default",
 "grade": 1,
 "count": 1,
 "strategy": 0,
 "controlBehavior": 0,
 "clusterMode": false
 }
]

在这里插入图片描述
4）启动应⽤，发现存在 关于 /testA 请求路径的流控规则
总结: 就是在 sentinel 启动的时候，去 nacos 上读取相关规则配置信息，实际上它规则的持久化，就是第三步，粘贴到nacos上保存下来，就算以后在 sentinel 上⾯修改了，重启应⽤以后也是有效的。

持久化配置应用截图
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

此时当我们重启 payment微服务的时候，
在这里插入图片描述
，他会默认去读取Nacos的配置的流控规则。
在这里插入图片描述
这时也会配置到Sentinel里面

凌晨里的无聊人
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
Redis-Sentinel高可用架构学习
10-21
1. Redis-Sentinel的基本概念：Redis-Sentinel是Redis官方推荐的高可用性解决方案，能够监控多个master-slave集群，自动切换master宕机后的服务。 2. Redis主从复制过程：主从同步原理是指Redis主服务器将数据复制...
sentinel入门案例
weixin_38829588的博客
03-20 532
1、新建一个springWeb项目 2、引入sentinel核心依赖 <!--sentinel核心依赖--> <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-core</artifactId> <version>1.7.2</version> </dependency>
sentinel 使用示例
weixin_43931625的博客
03-26 2192
sentinel 使用示例
Sentinel入门案例
qq_43223307的博客
11-23 580
官方文档：Sentinel · alibaba/spring-cloud-alibaba Wiki · GitHub 1、搭建Dashboard控制台 您可以从 release 页面 下载最新版本的控制台 jar 包。 Releases · alibaba/Sentinel · GitHub 下载的jar包（课前资料已下发），copy到一个没有空格或者中文的路径下，打开dos窗口切换到jar包所在目录。 执行：java -jar sentinel-dashboard-xxx.jar
springcloud3 Sentinel的搭建以及案例操作
健康平安的活着的专栏
01-25 1904
Sentinel是分布式系统流量控制的哨兵阿里开源的一套服务容错的综合性解决方案。sentinel 的使用可以分为两个部分:核心库（Java 客户端）：不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。控制台（Dashboard）：Dashboard 主要等。基于 Spring Boot 开发，打包后可以直接运行。
Java小案例-Sentinel的实现原理
最新发布
weixin_54449574的博客
12-23 1713
通过整篇文章的分析之后，再回头看看Sentinel的简介的内容，其实就能更好地理解Sentinel的定位和功能。Sentinel核心就是一堆统计数据和基于这些统计数据实现的流控和熔断的功能，源码并不复杂，而且Sentinel的代码写得非常好。
sentinel的下载和安装1.8.3
03-28
在这个主题中，我们将详细探讨 Sentinel 的下载、安装以及基本使用步骤。 首先，让我们来看如何下载 Sentinel。 Sentinel 的最新稳定版本是 1.8.3，你可以通过访问其官方网站或 GitHub 仓库来获取。通常，官方会...
sentinel 集群配置文件
10-17
- `port`: Sentinel监听的端口号，每个Sentinel实例都有自己的监听端口。 - `bind`: 指定Sentinel监听的IP地址，可以是多个。 - `sentinel monitor`: 定义要监控的主节点，格式为`sentinel monitor <master-name>...
Redis哨兵模式（Redis-Sentinel）实例配置.rar
09-11
2. **配置文件**：每个Sentinel实例都需要一个配置文件，其中包含要监控的主服务器信息，如IP地址、端口号以及Sentinel之间的通信端口。 3. **指定主服务器**：在Sentinel配置文件中，需要明确指出要监控的主服务器...
Redis Sentinel实现高可用配置的详细步骤
09-09
通过使用Sentinel系统，你可以确保即使在主节点出现故障时，数据仍然能够被可靠地访问，从而保证服务的连续性和数据的一致性。 在配置Redis Sentinel以实现高可用性时，以下是一些关键步骤和概念： 1. **安装Redis...
Sentinel 实战-集群限流
热门推荐
javaDB_EAD的专栏
05-25 1万+
集群流控 假如你的应用有多个实例，那么你设置了限流的规则之后，每一台应用的实例都会生效相同的流控规则，如下图所示： 假设我们设置了一个流控规则，qps是10，那么就会出现如上图所示的情况，当qps大于10时，实例中的 sentinel 就开始生效了，就会将超过阈值的请求 block 掉。 上图好像没什么问题，但是细想一下，我们可以发现还是会有这样的问题： 假设集群中有 10 台机器，我们给每台机器设置单机限流阈值为 10 qps，理想情况下整个集群的限流阈值就为 100 qps。不过实际情况
Sentinel使用示例、源码解析、滑动时间窗口算法等详解
Mona
06-08 899
sentinel的原始使用方式、注解方式使用、源码分析、计数器算法、漏桶算法、滑动时间窗口算法
Sentinel 简单使用案例
莫邪
12-11 765
Sentinel 的简单介绍与使用 gradle 中的主要配置 ext { set('springCloudAlibabaVersion', "2.2.1.RELEASE") } dependencies { implementation 'org.springframework.boot:spring-boot-starter-web' implementation 'com.alibaba.cloud:spring-cloud-starter-alibaba-sentinel'
Sentinel在订单大量服务调用的应用场景
杨航的专栏
03-28 881
Sentinel译为“哨兵”，顾名思义，面对您后台的大量服务/微服务，前置一个哨兵，但面对大量请求时，让后台服务有序被调用，但某些服务的不可用时，采用服务熔断降级等措施，让系统仍能平稳运行，不至于造成系统雪崩，典型应用场景： MQ中消息在某些时间段（比如订单交易的高峰期，秒杀期等）消息并发量非常大时，通过Sentinel起到“削峰填谷”的作用； 某个业务服务非常复杂，需要调用大量微服务，其...
sentinel使用与配置
dongxiexiaoadou的博客
05-28 7519
Sentinel 是面向分布式服务架构的高可用流量防护组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。 Sentinel 分为两个部分: 核心库（Java 客户端）：不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。 控制台（Dashboard）：基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。 Sentin
04-Sentinel限流熔断应用实践
无
04-18 211
04-Sentinel限流熔断应用实践 1.Sentinel简介 1.1背景分析 在我们日常生活中，经常会在淘宝、天猫、京东、拼多多等平台上参与商品的秒杀、抢购以及一些优惠活动，也会在节假日使用12306 手机APP抢火车票、高铁票，甚至有时候还要帮助同事、朋友为他们家小孩拉投票、刷票，这些场景都无一例外的会引起服务器流量的暴涨，导致网页无法显示、APP反应慢、功能无法正常运转，甚至会引起整个网站的崩溃。 我们如何在这些业务流量变化无常的情况下，保证各种业务安全运营，系统在任何情况下都不会崩溃呢？我们可以在
Redis 集群之哨兵模式（sentinel）及测试实例
weixin_43354181的博客
04-08 2472
上一节实现了Redis集群的主从模式，这一节来实现一下哨兵模式。 有了主从模式，为什么还会需要哨兵模式呢？ 上一节我们了解到，为了缓解服务器压力，我们可以对redis的系统实现一个主从分离，一个master主要实现写功能，一个或多个 slave 主要负责读功能。 那么这种模式有个什么问题呢， 万一我们的master 突然宕机了，不能提供写服务了，只能依靠slave实现读的功能，这种情况是很糟糕的。...
Sentinel实战应用
m0_46690280的博客
05-19 779
Sentinel实战应用Sentinel实战应用1 Sentinel核心库1.1 Sentinel介绍1.2 Sentinel核心功能1.2.1 流量控制 Sentinel实战应用 1 Sentinel核心库 Sentinel主页 https://github.com/alibaba/Sentinel/wiki/%E4%B8%BB%E9%A1%B5 1.1 Sentinel介绍 随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的流量控制组件，主要以流量为切入点
Sentinel配置使用
Andrew0219的博客
08-12 1158
info . put("msg" , "限流异常");info . put("msg" , "降级异常");info . put("msg" , "热点参数异常");info . put("msg" , "系统异常");info . put("msg" , "授权异常");} }
Sentinel面试题
07-28
你好！很高兴回答你的问题。对于Sentinel面试题，由于我并不拥有上下文信息，所以无法提供具体的面试题。但是，Sentinel是一种开源的分布式系统哨兵，用于实时监控和保护分布式系统的稳定性。在Sentinel面试中，可能会涉及以下方面的问题： 1. 了解Sentinel的背景和作用。 2. 解释Sentinel的核心概念和关键特性，如限流、熔断、降级等。 3. 介绍Sentinel的基本架构和工作原理。 4. 讨论如何在实际项目中使用Sentinel，并提供一些使用案例。 5. 探讨Sentinel在分布式系统中的优势和挑战。 6. 提及Sentinel与其他类似工具（如Hystrix）的比较。 希望这些信息能帮助你更好地准备Sentinel面试。如果你有任何具体的问题，请随时提问！

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

凌晨里的无聊人

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值