单点Redis的问题
- **数据丢失问题:**Redis是内存存储,服务重启可能会丢失数据
- **并发能力问题:**单节点Redis并发能力虽然不错,但也无法满足如618这样的高并发场景
- 故障恢复问题:如果Redis宕机,则服务不可用,需要一种自动的故障恢复手段
- **存储能力问题:**Redis基于内存,单节点能存储的数据量难以满足海量数据需求
解决问题
一、Redis持久化
二、Redis主从
三、Redis哨兵
四、Redis分片集群
单点Redis的问题
解决问题
一、Redis持久化
二、Redis主从
三、Redis哨兵
四、Redis分片集群
**报错:**Consider defining a bean of type ‘java.lang.String’ in your configuration
总结了网上的几种解决方案:
1、多余的@autowired
如:
2、待实例化的类里必须有默认的构造方法(即没有参数的那种)
1.引入sentinel依赖:
1 | <!--引入sentinel依赖--> |
1 | spring: |
(如果是在云服务器上安装的sentinel,localhost改为服务器的ip地址)
步骤一:在feing-api项目中定义类,实现FallbackFactory:
代码:
1 | import cn.itcast.feign.clients.UserClient; |
步骤二: 在feing-api项目中的DefaultFeignConfiguration类中将UserClientFallbackFactory注册为一个Bean:
代码:
1 | //将UserClientFallbackFactory注册到bean |
步骤三: 在feing-api项目中的UserClient接口中使用UserClientFallbackFactory:
代码:
1 | import cn.itcast.feign.clients.fallback.UserClientFallbackFactory; |
1 | import lombok.Data; |
导入依赖
1 | <dependency> |
编写结果数据通用类
1 | import com.fasterxml.jackson.annotation.JsonInclude; |
第1步:添加判断来源逻辑
代码:
1 | package cn.itcast.order.sentinel; |
第2步:编写过滤器–>给网关添加origin头
第3步: 重新启动,访问一个接口
第4步:
第5步:重新范访问上面的接口
8088是直接范文oder服务的,也就是绕过了网关,但是现在我们已经设置了授权规则,所以直接访问是不行的,你报错如下
现在我们通过网关来访问,网关的端口设置的是10010,用10010来访问
因为网关做了权限的校验,所以需要把权限加上
因此,通过上面的授权规则设置后,通过网关来访问的就可以,而通过浏览器直接访问的就不行
下面是黑马PPT的笔记
第1步:
代码:
1 | package cn.itcast.order.sentinel; |
第2步: 重启微服务,然后浏览器访问接口
第3步: 在sentinel中给端口设置响应的规则进行测试
(1)新增授权规则
(2)新增流控规则
下面是黑马PPT笔记
这一节知识就没有详细的操作笔记,需要观看黑马教程视频如下链接:
前言:
当我们服务重启,我们所配的所有规则就会丢失,因为sentinel会默认把这些规则保存在内存里,重启就自然丢失了。而在生产的环境下 肯定是不能容忍这样的问题的。所以我们就需要学习怎么将****sentinel的规则持久化。
如何避免因服务故障引起的雪崩问题?
超时处理:
线程隔离:
降级熔断:
Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址:https://sentinelguard.io/zh-cn/index.html
Sentinel 具有以下特征:
•丰富的应用场景:Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
•完备的实时监控:Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据,甚至 500 台以下规模的集群的汇总运行情况。
•广泛的开源生态:Sentinel 提供开箱即用的与其它开源框架/库的整合模块,例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
•完善的 SPI 扩展点:Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
流控效果是指请求达到流控阈值时应该采取的措施,包括三种:
• 快速失败:达到阈值后,新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
• warm up:预热模式,对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化,从一个较小值逐渐增加到最大阈值。
• 排队等待:让所有的请求按照先后次序排队执行,两个请求的间隔不能小于指定时长
warm up也叫预热模式,是应对服务冷启动的一种方案。请求阈值初始值是 threshold / coldFactor,持续指定时长后,逐渐提高到threshold值。而coldFactor的默认值是3.
添加规则:
借助JMeter测试:
启动后,通过的会随着预热过程而逐渐变多,拒绝逐渐变少
实时监控显示:
排队等待的有点:
(1) 发出的QPS是15,但大多数是通过的(10)而其它有的都是放到队列里面去了,小部分是拒绝的。
(2)而且不管你发出QPS的波动有多么剧烈,我放出的永远是均衡的,同过的都是10。这样对于微服务来说,波动的肯定不比均衡的好,所以这样的作用也是起到了流量整形的作用
步骤 1:注册RestTemplate
在order-service的OrderApplication中注册RestTemplate
1 | @SpringBootApplication |