sentinel 以及 seata 的windows搭建

服务雪崩效应，业务场景高并发应用

容错三板斧
1.超时机制 例如1s  每次请求在1s内必须返回，否则到点我就吧线程掐死 释放资源
一旦超时 就会释放资源 由于资源释放的比较快  应用不会呢么容易托死
2.隔离应用 比如说我

2.舱壁模式
https://blog.csdn.net/m0_63437643/article/details/122511776

3.断路器模式

sentinel 整合springboot 
1.sentinel 启动服务端口  2.pom 3.配置
我们需要整合Sentinel-dashboard(哨兵流量卫兵)我们需要整合sentinel-dashboard,
利用java-jar sentinel-dashboard  启动

起来了

我这里有2个项目 就模拟 sentinel ------->order 
sentinel 通过nacos 以及rabbion调用 order  此时给这个接口做一个限流策略

2. pom
	--sentinel--
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
    </dependency>
	--监控--
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>

#  yml 配置
server:
  port: 8081
spring:
  application:
    name: mall-sentinel
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080  # dashboard 的配置  
    nacos:
      discovery:
        server-addr: localhost:8848 # nacos配置

management:
  endpoints:
    web:
      exposure:
        include: '*'

当我们用localhost:8080 登录 之后用 sentinel sentinel 登录  就是这个页面 
当放生请求的调用时候 就会有对应的服务节点

当我们访问localhost:8081  
--->
也就是sentinel调用order的时候 在sentinel页面上就会有对应的链路关系了

可以看到我们是基于接口名命名资源的 ，并且此时1分钟过了7个qps ，我们可以吧这个请求设置一个流控规则
让他1分钟过1个  多余的报错

还可以配置warn up 就是让你缓慢上升的过程
快速失败是你最高峰1000个qps， 瞬时流量到达1000再往上就通过不了
配置warn up  就会你比如说多长时间达到1000个  这样的场景一般在于你项目启动的时候 比如说连接池没有初始化好
 我允许你流量慢慢的增加 经过多长时间才达到你的阈值
 
 排队等待就是你匀速器模式 比如1s 经过2个qps 

当我们点击过多的时候他就会报错

可能近期做的是中台系统吧 基于功能想下 sentinel有那些接口
1.服务注册 
2.
3.

------------------------------------------------------------------------------->>>
上述就是sentinel 的简单应用 我们看下seata 的分布式事务

我们知道事务，要么一起完成　要么一起失败　　事务的特性就是acid
原子性

一致性
持久性
隔离性
我们可以用    @Transactional  就可以让本地事务生效  如果有异常我们就会让她回滚

当我们遇到分布式事务的时候该怎么去解决

我这里还是2个服务 一个用户服务一个order  [userService.save(userEntity); 保存用户]
【 orderFeignService.saveFirst(orderEntity);保存订单】

在order 这边都一样的 我的saveFirst  只是模拟 其他的微服务  
也就是说我正常情况下  一个请求应该是这样的

我们访问user 的端口号 
http://localhost:8040/user/save
正常情况下 user 中insert 1条数据
		 order中insert2条数据

 也就是说此时分3步
 第一步 insert user
 第二步 insert order
 第三步 insert order
 但是如果此时在第三步 有异常了报错 此时 @Transactional 会进行本地回滚策略
 他会抛异常 抛到 user 服务中 user 也本地回滚 但是第二步 已经Insert 成功了
就会造成一种情况 明明已经失败了 回滚了 但是此时还会插入库中一条数据

我吧之前user和order 表中数据都清了， 在这里加一个int i=1/0 模拟报错

在重新启动order 服务  
访问 http://localhost:8040/user/save
此时程序会报错 但是order中已经insert 一条数据了 这个就是 分布式事务

seata 的搭建看这里
https://blog.csdn.net/jixieguang/article/details/110621561

这里有一个两阶段提交
第一阶段就是 只执行 不提交（会导致锁表）

就类似于这样的