zoukankan      html  css  js  c++  java
  • SpringCloud 网飞系 转换阿里系2

    本次内容概述 1. seata集成   2. feign + sentinel +seata + @ControllerAdvice 互相影响产生的事务问题整理

    1.seata部署

    2.seata配置

    这两步可以参考很多部署文档,把比较容易出问题的地方说明下

    3.测试

    一些总结说明:

    熔断的概念不能和下游服务挂掉,注册中心不可用混淆。熔断应理解为多次超时达到熔断阈值而直接不进入代码块。

    结合上一篇sentinel的配置可以得到如下结论

      本地事务在不配置blockHandler、fallback情况下,熔断或流控抛出异常可被@Transactional拦截并保证事务;

      feign事务在不配置blockHandler、fallback类的情况下,熔断或流控抛出异常可被@Transactional拦截并保证事务;

     

    以上述链路为例,分别测试如下几种情况

    首先是正常情况下,全部提交;可以看下几个关键日志的地方。

      全局事务

      场景1 下游服务挂了

        直接上游可以拿到ribbon异常并回滚

        把order-api停掉。上游服务feign客户端能马上感知到服务不可用的异常。

     

        这里我们停order-api还不够明显,account-api还没执行。我们换下,就能发现有一个挂了,其他都能回滚。

     

      场景2 下游服务超时了

        直接上有可以拿到ribbon异常并回滚,通知下游的事务也一起回滚

        同理,我们都对account-api下手,给他加个sleep6秒的操作,因为我们ribbon超时设置的5秒。制作超时的场景。

        显然也拿到了超时异常,可以直接回滚。

      场景3 下游服务熔断了

         直接上游可以拿到sentinel异常并回滚,在场景2的基础上,我们多试几次来达到sentinel的阈值模拟熔断。

        进入我们的feign降级熔断。值得一提,这里我们不管对本地还是feign的sentinel都是不直接捕获异常的。所以seata是能感知到

        与场景2不同的是,下游熔断以后是直接返回拿到异常而不去尝试请求的,所以seata根本就不需要管理熔断的服务,只要把其他的服务回滚即可。

      场景4 下游服务遇到业务异常了

        此时如果我们配置了全局异常捕获@ControllerAdvice 对seata服务来说就感知不到异常。我们需要在@ControllerAdvice手动获取xid并回滚,seata通知所有相同的xid事务回滚。

        我们给account-api随便给一个异常,观察。

        这里实际上seata是没有感知到异常的。只是我们在全局异常捕获的地方手动获取当前xid并手动回滚,seata通知其他一样的xid事务回滚;

        这里有个小细节,如果account-api的地方加了本地@Transactional,则本地自动回滚,seata不去重复操作了。

    组件gitee  https://gitee.com/xuetieqi/component-alibaba

    项目gitee  https://gitee.com/xuetieqi/base-server-alibaba

      

  • 相关阅读:
    some tips
    ORA00847: MEMORY_TARGET/MEMORY_MAX_TARGET and LOCK_SGA cannot be set together
    Chapter 01Overview of Oracle 9i Database Perfomrmance Tuning
    Chapter 02Diagnostic and Tuning Tools
    变量与常用符号
    Chapter 18Tuning the Operating System
    标准输入输出
    Trace files
    DBADeveloped Tools
    Chapter 03Database Configuration and IO Issues
  • 原文地址:https://www.cnblogs.com/xuetieqi/p/15303461.html
Copyright © 2011-2022 走看看