深圳精品网站制作,宁波网站建设公司比较好,_沈阳做网站,全国企业信息查询网站SpringCloud系列知识快速复习 -- part 2#xff08;Sentinel微服务保护#xff0c;Seata分布式事务#xff0c;Redis分布式缓存和多级缓存Sentinel微服务保护什么是雪崩问题#xff1f;解决方法服务保护技术对比流量控制簇点链路Sentinel流控模式流控效果热点参数限流隔离和…
SpringCloud系列知识快速复习 -- part 2Sentinel微服务保护Seata分布式事务Redis分布式缓存和多级缓存Sentinel微服务保护什么是雪崩问题解决方法服务保护技术对比流量控制簇点链路Sentinel流控模式流控效果热点参数限流隔离和降级线程隔离熔断降级授权规则规则持久化Seata分布式事务CAP定理Base理论解决分布式事务的思路Seata四种不同的分布式事务解决方案XA模式流程优缺点AT模式流程优缺点TCC模式流程优缺点SAGA模式流程优缺点Redis分布式缓存Redis缓存预热Redis持久化RDB原理AOF原理AOF文件重写RDB与AOF对比主从数据同步原理全量同步增量同步主从同步优化Redis哨兵集群监控原理集群故障恢复原理故障转移步骤RedisTemplate分片集群分片集群特征插槽原理多级缓存JVM进程缓存Nginx缓存OpenRestyCJSON工具类本地缓存API缓存同步Sentinel微服务保护
什么是雪崩问题
微服务之间相互调用因为调用链中的一个服务故障引起整个链路都无法访问的情况。
解决方法
限流是对服务的保护避免因瞬间高并发流量而导致服务故障进而避免雪崩。是一种预防措施。
超时处理、线程隔离、降级熔断是在部分服务故障时将故障控制在一定范围避免雪崩。是一种补救措施。
服务保护技术对比
Netfix HystrixSentinelResilience4J
SentinelHystrix隔离策略信号量隔离线程池隔离/信号量隔离熔断降级策略基于慢调用比例或异常比例基于失败比率实时指标实现滑动窗口滑动窗口基于 RxJava规则配置支持多种数据源支持多种数据源扩展性多个扩展点插件的形式基于注解的支持支持支持限流基于 QPS支持基于调用关系的限流有限的支持流量整形支持慢启动、匀速排队模式不支持系统自适应保护支持不支持控制台开箱即用可配置规则、查看秒级监控、机器发现等不完善常见框架的适配Servlet、Spring Cloud、Dubbo、gRPC 等Servlet、Spring Cloud Netflix
流量控制
簇点链路
当请求进入微服务时首先会访问DispatcherServlet然后进入Controller、Service、Mapper这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。
默认情况下sentinel会监控SpringMVC的每一个端点Endpoint也就是controller中的方法因此SpringMVC的每一个端点Endpoint就是调用链路中的一个资源。
Sentinel流控模式
流控模式有哪些
•直接对当前资源限流
•关联高优先级资源触发阈值对低优先级资源限流。
•链路阈值统计时只统计从指定资源进入当前资源的请求是对请求来源的限流
满足下面条件可以使用关联模式
两个有竞争关系的资源一个优先级较高一个优先级较低
流控效果 快速失败QPS超过阈值时拒绝新的请求 warm up QPS超过阈值时拒绝新的请求QPS阈值是逐渐提升的可以避免冷启动时高并发导致服务宕机。 排队等待请求会进入队列按照阈值允许的时间间隔依次执行请求如果请求预期等待时长大于超时时间直接拒绝
热点参数限流
之前的限流是统计访问某个资源的所有请求判断是否超过QPS阈值。而热点参数限流是分别统计特点参数值的请求判断是否超过QPS阈值。
隔离和降级
线程隔离调用者在调用服务提供者时给每个调用的请求分配独立线程池出现故障时最多消耗这个线程池内资源避免把调用者的所有资源耗尽。 熔断降级是在调用方这边加入断路器统计对服务提供者的调用如果调用的失败比例过高则熔断该业务不允许访问该服务的提供者了。
Sentinel支持的雪崩解决方案
线程隔离仓壁模式降级熔断
Feign整合Sentinel的步骤
在application.yml中配置feign.sentienl.enabletrue给FeignClient编写FallbackFactory并注册为Bean将FallbackFactory配置到FeignClient
线程隔离
线程隔离有两种方式实现 线程池隔离 给每个服务调用业务分配一个线程池利用线程池本身实现隔离效果 信号量隔离Sentinel默认采用 不创建线程池而是计数器模式记录业务使用的线程数量达到信号量上限时禁止新的请求。
信号量隔离的特点是
基于计数器模式简单开销小
线程池隔离的特点是
基于线程池模式有额外开销但隔离控制更强
熔断降级
其思路是由断路器统计服务调用的异常比例、慢请求比例如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求而当服务恢复时断路器会放行访问该服务的请求
状态机包括三个状态
closed关闭状态断路器放行所有请求并开始统计异常比例、慢请求比例。超过阈值则切换到open状态open打开状态服务调用被熔断访问被熔断服务的请求会被拒绝快速失败直接走降级逻辑。Open状态5秒后会进入half-open状态half-open半开状态放行一次请求根据执行结果来判断接下来的操作。 请求成功则切换到closed状态请求失败则切换到open状态
断路器熔断策略有三种慢调用、异常比例、异常数 慢调用业务的响应时长RT大于指定时长的请求认定为慢调用请求。在指定时间内如果请求数量超过设定的最小数量慢调用比例大于设定的阈值则触发熔断。 异常比例或异常数统计指定时间内的调用如果调用次数超过指定请求数并且出现异常的比例达到设定的比例阈值或超过指定异常数则触发熔断。
授权规则
对请求方来源做判断和控制
授权规则可以对调用方的来源做控制有白名单和黑名单两种方式。 白名单来源origin在白名单内的调用者允许访问 黑名单来源origin在黑名单内的调用者不允许访问
规则持久化
现在sentinel的所有规则都是内存存储重启后所有规则都会丢失。在生产环境下我们必须确保这些规则的持久化避免丢失。
规则是否能持久化取决于规则管理模式sentinel支持三种规则管理模式
原始模式Sentinel的默认模式将规则保存在内存重启服务会丢失。pull模式push模式
pull模式控制台将配置的规则推送到Sentinel客户端而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询更新本地规则。
push模式控制台将配置规则推送到远程配置中心例如Nacos。Sentinel客户端监听Nacos获取配置变更的推送消息完成本地配置更新。
Seata分布式事务
分布式事务就是指不是在单个服务或单个数据库架构下产生的事务例如
跨数据源的分布式事务跨服务的分布式事务综合情况
CAP定理
Consistency一致性Availability可用性Partition tolerance 分区容错性 因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接形成独立分区在集群出现分区时整个系统也要持续对外提供服务
在P一定会出现的情况下A和C之间只能实现一个
Base理论
BASE理论是对CAP的一种解决思路包含三个思想
Basically Available 基本可用 分布式系统在出现故障时允许损失部分可用性即保证核心可用。Soft State软状态) 在一定时间内允许出现中间状态比如临时的不一致状态。Eventually Consistent最终一致性 虽然无法保证强一致性但是在软状态结束后最终达到数据一致。
解决分布式事务的思路
分布式事务最大的问题是各个子事务的一致性问题因此可以借鉴CAP定理和BASE理论有两种解决思路 AP模式各子事务分别执行和提交允许出现结果不一致然后采用弥补措施恢复数据即可实现最终一致。 CP模式各个子事务执行后互相等待同时提交同时回滚达成强一致。但事务等待过程中处于弱可用状态
子系统事务称为分支事务有关联的各个分支事务在一起称为全局事务
Seata
Seata事务管理中有三个重要的角色 TC (Transaction Coordinator) - 事务协调者 维护全局和分支事务的状态协调全局事务提交或回滚。 TM (Transaction Manager) - 事务管理器 定义全局事务的范围、开始全局事务、提交或回滚全局事务。 RM (Resource Manager) - 资源管理器 管理分支事务处理的资源与TC交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或回滚。 四种不同的分布式事务解决方案
XA模式强一致性分阶段事务模式牺牲了一定的可用性无业务侵入TCC模式最终一致的分阶段事务模式有业务侵入AT模式最终一致的分阶段事务模式无业务侵入也是Seata的默认模式SAGA模式长事务模式有业务侵入
无论哪种方案都离不开TC也就是事务的协调者。
XA模式
基于两阶段提交
流程
RM一阶段的工作
注册分支事务到TC执行分支业务sql但不提交(继续持有数据库锁)报告执行状态到TC
TC二阶段的工作 TC检测各分支事务执行状态 a. 如果都成功通知所有RM提交事务 b. 如果有失败通知所有RM回滚事务
RM二阶段的工作
接收TC指令提交或回滚事务
优缺点
XA模式的优点是什么
事务的强一致性满足ACID原则。常用数据库都支持实现简单并且没有代码侵入
XA模式的缺点是什么
因为一阶段需要锁定数据库资源等待二阶段结束才释放性能较差依赖关系型数据库实现事务
AT模式 流程
阶段一RM的工作
注册分支事务记录undo-log数据快照执行业务sql并提交报告事务状态
阶段二提交时RM的工作
删除undo-log即可
阶段二回滚时RM的工作
根据undo-log恢复数据到更新前
缺弥补了XA模型中资源锁定周期过长的缺陷
AT模式与XA模式最大的区别是什么
XA模式一阶段不提交事务锁定资源AT模式一阶段直接提交不锁定资源。XA模式依赖数据库机制实现回滚AT模式利用数据快照实现数据回滚。XA模式强一致AT模式最终一致
优缺点
AT模式的优点
一阶段完成直接提交事务释放数据库资源性能比较好利用全局锁实现读写隔离没有代码侵入框架自动完成回滚和提交
AT模式的缺点
两阶段之间属于软状态属于最终一致框架的快照功能会影响性能但比XA模式要好很多需要导入数据库表记录全局锁防止脏写问题
TCC模式
TCC模式与AT模式非常相似每阶段都是独立事务不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法 流程 Try资源的检测和预留 Confirm完成资源操作业务要求 Try 成功 Confirm 一定要能成功。 Cancel预留资源释放可以理解为try的反向操作。
优缺点
TCC模式的每个阶段是做什么的
Try资源检查和预留Confirm业务执行和提交Cancel预留资源的释放
TCC的优点是什么
一阶段完成直接提交事务释放数据库资源性能好相比AT模型无需生成快照无需使用全局锁性能最强不依赖数据库事务而是依赖补偿操作可以用于非事务型数据库
TCC的缺点是什么
有代码侵入需要人为编写try、Confirm和Cancel接口太麻烦软状态事务是最终一致需要考虑Confirm和Cancel的失败情况做好幂等处理空回滚和事务悬挂
SAGA模式 流程
Saga也分为两个阶段
一阶段直接提交本地事务二阶段成功则什么都不做失败则通过编写补偿业务来回滚
优缺点
优点
事务参与者可以基于事件驱动实现异步调用吞吐高一阶段直接提交事务无锁性能好不用编写TCC中的三个阶段实现简单
缺点
软状态持续时间不确定时效性差没有锁没有事务隔离会有脏写
Redis分布式缓存
Redis缓存预热
Redis缓存会面临冷启动问题
冷启动服务刚刚启动时Redis中并没有缓存如果所有商品数据都在第一次查询时添加缓存可能会给数据库带来较大压力。
缓存预热在实际开发中我们可以利用大数据统计用户访问的热点数据在项目启动时将这些热点数据提前查询并保存到Redis中。
Redis持久化
Redis有两种持久化方案
RDB持久化AOF持久化
RDB持久化在四种情况下会执行
执行save命令执行bgsave命令Redis停机时触发RDB条件时
RDB原理
bgsave开始时会fork主进程得到子进程子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。
fork采用的是copy-on-write技术
当主进程执行读操作时访问共享内存当主进程执行写操作时则会拷贝一份数据执行写操作。 RDB方式bgsave的基本流程
fork主进程得到一个子进程共享内存空间子进程读取内存数据并写入新的RDB文件用新RDB文件替换旧的RDB文件
RDB会在什么时候执行save 60 1000代表什么含义
默认是服务停止时代表60秒内至少执行1000次修改则触发RDB
RDB的缺点
RDB执行间隔时间长两次RDB之间写入数据有丢失的风险fork子进程、压缩、写出RDB文件都比较耗时
AOF原理
AOF全称为Append Only File追加文件。Redis处理的每一个写命令都会记录在AOF文件可以看做是命令日志文件。
AOF文件重写
因为是记录命令AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作但只有最后一次写操作才有意义。通过执行bgrewriteaof命令可以让AOF文件执行重写功能用最少的命令达到相同效果。
RDB与AOF对比 主从数据同步原理
全量同步 slave节点请求增量同步master节点判断replid发现不一致进行全量同步master将完整内存数据生成RDB发送RDB到slaveslave清空本地数据加载master的RDBmaster将RDB期间的命令记录在repl_baklog并持续将log中的命令发送给slaveslave执行接收到的命令保持与master之间的同步
主从第一次建立连接时会执行全量同步将master节点的所有数据都拷贝给slave节点 master如何得知salve是第一次来连接呢
Replication Id简称replid是数据集的标记id一致则说明是同一数据集。每一个master都有唯一的replidslave则会继承master节点的replidoffset偏移量随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset说明slave数据落后于master需要更新。master判断一个节点是否是第一次同步的依据就是看replid是否一致
增量同步
全量同步需要先做RDB然后将RDB文件通过网络传输个slave成本太高了。因此除了第一次做全量同步其它大多数时候slave与master都是做增量同步 master怎么知道slave与自己的数据差异在哪里呢?
这就要说到全量同步时的repl_baklog文件了。
这个文件是一个固定大小的数组只不过数组是环形也就是说角标到达数组末尾后会再次从0开始读写这样数组头部的数据就会被覆盖。
repl_baklog中会记录Redis处理过的命令日志及offset包括master当前的offset和slave已经拷贝到的offset
repl_baklog大小有上限写满后会覆盖最早的数据。如果slave断开时间过久导致尚未备份的数据被覆盖则无法基于log做增量同步只能再次全量同步。
主从同步优化
在master中配置repl-diskless-sync yes启用无磁盘复制避免全量同步时的磁盘IO。Redis单节点上的内存占用不要太大减少RDB导致的过多磁盘IO适当提高repl_baklog的大小发现slave宕机时尽快实现故障恢复尽可能避免全量同步限制一个master上的slave节点数量如果实在是太多slave则可以采用主-从-从链式结构减少master压力
简述全量同步和增量同步区别
全量同步master将完整内存数据生成RDB发送RDB到slave。后续命令则记录在repl_baklog逐个发送给slave。增量同步slave提交自己的offset到mastermaster获取repl_baklog中从offset之后的命令给slave
什么时候执行全量同步
slave节点第一次连接master节点时slave节点断开时间太久repl_baklog中的offset已经被覆盖时
什么时候执行增量同步
slave节点断开又恢复并且在repl_baklog中能找到offset时
Redis哨兵
哨兵的作用如下
监控Sentinel 会不断检查您的master和slave是否按预期工作自动故障恢复如果master故障Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主通知Sentinel充当Redis客户端的服务发现来源当集群发生故障转移时会将最新信息推送给Redis的客户端
集群监控原理
Sentinel基于心跳机制监测服务状态每隔1秒向集群的每个实例发送ping命令
•主观下线如果某sentinel节点发现某实例未在规定时间响应则认为该实例主观下线。
•客观下线若超过指定数量quorum的sentinel都认为该实例主观下线则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。
集群故障恢复原理
一旦发现master故障sentinel需要在salve中选择一个作为新的master选择依据是这样的
首先会判断slave节点与master节点断开时间长短如果超过指定值down-after-milliseconds * 10则会排除该slave节点然后判断slave节点的slave-priority值越小优先级越高如果是0则永不参与选举如果slave-prority一样则判断slave节点的offset值越大说明数据越新优先级越高最后是判断slave节点的运行id大小越小优先级越高。
故障转移步骤
sentinel给备选的slave1节点发送slaveof no one命令让该节点成为mastersentinel给所有其它slave发送slaveof 192.168.150.101 7002 命令让这些slave成为新master的从节点开始从新的master上同步数据。最后sentinel将故障节点标记为slave当故障节点恢复后会自动成为新的master的slave节点
RedisTemplate
在Sentinel集群监管下的Redis主从集群其节点会因为自动故障转移而发生变化Redis的客户端必须感知这种变化及时更新连接信息。Spring的RedisTemplate底层利用lettuce实现了节点的感知和自动切换。
个bean中配置的有四种读写策略包括
MASTER从主节点读取MASTER_PREFERRED优先从master节点读取master不可用才读取replicaREPLICA从slavereplica节点读取REPLICA _PREFERRED优先从slavereplica节点读取所有的slave都不可用才读取master
分片集群
主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决 海量数据存储问题 高并发写的问题
分片集群特征 集群中有多个master每个master保存不同数据 每个master都可以有多个slave节点 master之间通过ping监测彼此健康状态 客户端请求可以访问集群任意节点最终都会被转发到正确节点
插槽原理
Redis会把每一个master节点映射到0~16383共16384个插槽hash slot上查看集群信息时就能看到
Redis如何判断某个key应该在哪个实例
将16384个插槽分配到不同的实例根据key的有效部分计算哈希值对16384取余余数作为插槽寻找插槽所在实例即可
如何将同一类数据固定的保存在同一个Redis实例
这一类数据使用相同的有效部分例如key都以{typeId}为前缀
多级缓存
多级缓存就是充分利用请求处理的每个环节分别添加缓存减轻Tomcat压力提升服务性能
浏览器访问静态资源时优先读取浏览器本地缓存访问非静态资源ajax查询数据时访问服务端请求到达Nginx后优先读取Nginx本地缓存如果Nginx本地缓存未命中则去直接查询Redis不经过Tomcat如果Redis查询未命中则查询Tomcat请求进入Tomcat后优先查询JVM进程缓存如果JVM进程缓存未命中则查询数据库
JVM进程缓存
Caffeine是一个基于Java8开发的提供了近乎最佳命中率的高性能的本地缓存库。目前Spring内部的缓存使用的就是Caffeine。GitHub地址https://github.com/ben-manes/caffeine
Caffeine的性能非常好
Nginx缓存
OpenResty
OpenResty 是一个基于 Nginx的高性能 Web 平台用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。具备下列特点
具备Nginx的完整功能基于Lua语言进行扩展集成了大量精良的 Lua 库、第三方模块允许使用Lua自定义业务逻辑、自定义库
CJSON工具类
OpenResty提供了一个cjson的模块用来处理JSON的序列化和反序列化。
本地缓存API
OpenResty为Nginx提供了shard dict的功能可以在nginx的多个worker之间共享数据实现缓存功能
缓存同步
缓存数据同步的常见方式有三种
设置有效期给缓存设置有效期到期后自动删除。再次查询时更新
优势简单、方便缺点时效性差缓存过期之前可能不一致场景更新频率较低时效性要求低的业务
同步双写 在修改数据库的同时直接修改缓存
优势时效性强缓存与数据库强一致缺点有代码侵入耦合度高场景对一致性、时效性要求较高的缓存数据
异步通知 修改数据库时发送事件通知相关服务监听到通知后修改缓存数据
优势低耦合可以同时通知多个缓存服务缺点时效性一般可能存在中间不一致状态场景时效性要求一般有多个服务需要同步
而异步实现又可以基于MQ或者Canal来实现 MQ Canal Canal是基于mysql的主从同步来实现的MySQL主从同步的原理如下 1MySQL master 将数据变更写入二进制日志( binary log其中记录的数据叫做binary log events 2MySQL slave 将 master 的 binary log events拷贝到它的中继日志(relay log) 3MySQL slave 重放 relay log 中事件将数据变更反映它自己的数据
