学习地址:
https://spring-cloud-alibaba-group.github.io/github-pages/greenwich/spring-cloud-alibaba.html
seata: http://seata.io/zh-cn/
http://seata.io/zh-cn/docs/overview/what-is-seata.html
sentinel:https://github.com/alibaba/Sentinel
nacos: https://github.com/alibaba/nacos/releases/tag/1.3.0
服务提供者 2
消费者 1
http://localhost:9001/payment/nacos/1
http://localhost:83/consumer/payment/nacos/1
nacos 既支持Ap 也支持CP
可以通过命令进行切换
配置中心
多项目
多环境
namespace+group+dataid
namespace集群环境
group:
nacos 集群配置 + 持久化配置
linux版本
gitbub地址:https://github.com/alibaba/Sentinel
--异常 DegradeException
--sentinel的熔断机制是没有半开的这种状态的,要么死要么活
--先通断后降级
1.默认是懒加载机制,执行一次才能访问,下载jar包,8080端口,查看前台服务
2.初始化工程,簇点链路、流控模式
3.流控规则
基本介绍
流控模式
直接(默认)
直接快速失败 QPS(进入到程序之前) 线程数(进入到程序之后)
在快速访问失败之后,是否有用户自定义的失败提示呢
不一定都是blocked by sentinel (flow limiting ) ????
Blocked by Sentinel (flow limiting)
关联
B惹事情,A挂了
链路
多个请求访问同一个微服务
流控效果
快速失败
预热 冷启动的方式 warm up
一下子启动10万的请求,直接打死微服务
阈值
冷加载因子coldfoctoe 默认是3
:阈值/冷加载因子 才会达到阈
--- 秒杀系统
排队等待
匀速排队 --- 漏桶算法???
4.降级规则 也叫降级策略
RT
平均相应时长 妙级 + 时间窗口期(QPS>=5) 同时满足 触发该规则
RT最大4900 可以通过命令设置 -Dcsp.sentinel.max.rt=XXXX
异常比例
设置的范围是【0到1】之间
分钟级
QPS>=5 + 异常比例数>阈值 触发降级
时间窗口期 过了之后 关闭降级
异常数
当资源1分钟之内的异常数达到阈值后进行熔断
分钟级
异常数达到阈值就会触发降级
时间窗口期??? 过了之后 关闭降级
5.热点key限流
https://github.com/alibaba/Sentinel/wiki/%E7%83%AD%E7%82%B9%E5%8F%82%E6%95%B0%E9%99%90%E6%B5%81
仅仅支持QPS模式
@SentinelResource 兜底方法
@GetMapping("/test")
@SentinelResource(value = "myMethod",blockHandler = "m2")
public Result doSomething(@RequestParam("uid")String uid ,Required = false ,
@RequestParam("type")int type,Required = false)
{
// some logic here...
}
//兜底方法
public Result m2(String uid, int type ,BlockException exception) {
}
---如果没有兜底方法,则显示错误页面
配置索引为0,检测的是请求方法中的第一个参数
路径显示
XXXXXX/test?uid=1111 效果Ok
XXXXXX/test?type=000 效果not ok --因为没有做配置索引
参数例外项:
参数支持:8中基本类型和String类型
在高级选项中做设置
在这种情况下出现异常时,则不做做处理
@SentinelResource:主管配置出错,运行出错则需要走异常处理
6.系统规则
LOAD
RT
线程数
入口QPS
CPU使用率
7.@SentinelResource
按照资源名称限流+后续处理
按照url地址限流+后续处理
兜底方法存在的问题
系统默认的,没有体现出业务要求
代码狗和,不直观
每个业务方法都有一个兜底方法,代码膨胀
全局统一的处理方法没有体现
客户自定义限流处理逻辑
更多注解属性说明
8.服务熔断功能
sentinel整合ribbon+openfeign+fallback
ribbon
启动nacos、sentinel
提供者9003/9004
建module
pom
yml
主启动类
业务类
测试地址
消费者84
配置config类,引入resttemplate
@SentinelResource(value = "myMethod",blockHandler = "m2",fallback = "m2",exceptionsToIngore = {})
openfeign
加pom
yml中增加fengin对sentinel的支持
fengin:
sentinel:
enable:true
主启动了增加openfengin注解支持
新增接口,@FenginClient(value = "",fallback = XXX.class)
新增fallbackServiceImpl实现类,即XXX
熔断框架比较
9.规则持久化
配置到nacos中
在sentinel中配置的流控规则,重新启动sentinel后,规则就没有了
pom
增加sentinel-datasource-nacos
yml
增加nacos 数据源配置
1.分布式事务的问题
2.seata介绍
http://seata.io/zh-cn/docs/overview/terminology.html
全局事务ID
三个组件:
TC - 事务协调者
维护全局和分支事务的状态,驱动全局事务提交或回滚。
TM - 事务管理器
定义全局事务的范围:开始全局事务、提交或回滚全局事务。
RM - 资源管理器
管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
处理过程
1.TM向TC申请开启一个全局事务.全局事务创建成功并生成一个全局唯一XID
2.XID在微服务调用链路的上下文中传播
3.RM向TC注册分支事务,将其纳入XID对应全局事务管理
4.TM向TC发起针对XID的全局提交或者回滚决议
5.TC调度XID下管辖的全局分支事务完成提交或者回滚请求
3.seata-server安装 相当于一个分布式事务服务器
官网地址
下载版本
修改seataconf中的file.conf中的配置
备份原来的文件
主要修改:自定义事务组名称+事务日志存储模式+数据库连接信息
file.conf
service模块
:自定义事务组名称
store模块
:事务日志存储模式 为DB
在mysql数据库中创建数据库
在创建好的数据库中插入数据(seata 自带的sql)
修改register.conf配置文件
调整seata的注册地址为nacos,配置nacos的地址信息
启动nacos 端口号8848
启动seata
4.订单/库存/业务账户数据库准备
启动nacos、seata两个服务
三个微服务 订单 库存 账户
下订单-扣库存-减余额-该订单状态
创建三个数据库seata_order订单、seata_storage库存、seata_account账户
在三个数据库中创建对应的业务表
按照上述三个库创建对应的回滚日志表:在srata conf有一个叫 db_undo_log.sql
5.订单/库存/业务账户微服务准备
Order_mudule
创建module stata-order-service2001
pom
yml
file.conf
register.conf
domain(传输实体、表实体)
DAO实现
Service接口和实现
Controller
config配置
主启动类
Storge_mudule
Account_mudule
6.test
---树逻辑
---
高可用、低延迟、高QPS
分布式事务ID
为什么UUID会导致入库性能变差?
1.无需,无法预测他的生成顺序,不能通过递增有序的数字
2.注解,ID作为主键在特定的环境中会存在一些问题
3.索引,B+树索引分裂
数据库自增主键
单机:
集群分布式:
基于redis生成全局唯一ID
increase increaseby
除了设置步长以外,还需要关注过期时间
配置麻烦XXXX