vlambda博客
学习文章列表

关于Hystrix超时机制和线程状态的测试观察和个人理解

我们在使用Hystrix时,大部分情况下都是直接基于SpringCloud的相关注解来完成请求调用的。我们有个项目中是手动创建HystrixCommand来包裹RestTemplate发起请求的。但是在服务运行过程中,发现一个情况,就是当HystrixCommand超时返回fallback结果后,RestTemplate请求过程还没有结束,导致线程池占用较多。

这里通过一个简单的测试,对RestTemplate和HystrixCommand设置不同的超时时间,来观察在HystrixCommand执行过程中的细节。

测试观察

模拟外部服务:

创建一个springboot服务,提供一个接口:等待5秒后返回数据

@RestController
public class DataController {

    @RequestMapping("queryData")
    public String queryData() {
        // 等待5s后,返回随机字符串
        long sleepTime = 5000;
        try {
            Thread.sleep(sleepTime);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return UUID.randomUUID().toString();
    }
}
测试代码:
public class HystrixCommandTest {

    private static final SimpleDateFormat df = new SimpleDateFormat("HH:mm:ss");

    // http请求超时时间
    private static final int HTTP_TIMEOUT = 10000;
    // hystrix超时时间
    private static final int HYSTRIX_TIMEOUT = 10000;

    private RestTemplate restTemplate;

    @Before
    public void init() {
        HttpComponentsClientHttpRequestFactory httpRequestFactory = new HttpComponentsClientHttpRequestFactory();
        httpRequestFactory.setReadTimeout(HTTP_TIMEOUT);
        restTemplate = new RestTemplate(httpRequestFactory);
    }

    @Test
    public void test() {
        // 创建HystrixCommand.Setter
        HystrixCommandProperties.Setter propSetter = HystrixCommandProperties.Setter()
                .withExecutionTimeoutEnabled(true)  //开启超时机制
                .withExecutionTimeoutInMilliseconds(HYSTRIX_TIMEOUT)    //设置超时时间
                .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.THREAD) //线程隔离
                .withExecutionIsolationThreadInterruptOnTimeout(true);  //这里设置超时中断线程,但其实没有实际效果
        HystrixCommand.Setter setter = HystrixCommand.Setter
                .withGroupKey(HystrixCommandGroupKey.Factory.asKey("queryData"))
                .andCommandPropertiesDefaults(propSetter);

        // 通过Setter创建创建HystrixCommand
        HystrixCommand<String> hystrixCommand = new HystrixCommand<String>(setter) {
            @Override
            protected String run() throws Exception {
                // 发起http请求
                print("send request");
                String result = restTemplate.getForObject("http://127.0.0.1:9001/queryData", String.class);
                print("get response");
                return result;
            }

            @Override
            protected String getFallback() {
                print("fallback");
                return null;
            }
        };
        print("execute command");
        // 执行HystrixCommand
        String result = hystrixCommand.execute();
        print("get result=" + result);
        // 阻塞main线程,防止程序终止
        while (true) {
        }
    }

    private void print(String msg) {
        System.out.println(df.format(new Date()) + " [" + Thread.currentThread().getName() + "]:" + msg);
    }
}
测试场景1:RestTemplate和HystrixCommand都没有超时

参数设置:

  • RestTemplate超时时间>接口响应时间(5s),Hystrix超时时间>接口响应时间(5s)

  • HTTP_TIMEOUT和HYSTRIX_TIMEOUT都设置为10s

输出结果:

  • 关于Hystrix超时机制和线程状态的测试观察和个人理解
  • 主线程创建HystrixCommand并执行,Hystrix创建子线程发起http请求,5秒后收到响应。最后主线程收到正确响应结果。

测试场景2:RestTemplate超时,HystrixCommand没有超时

参数设置:

  • RestTemplate超时时间<接口响应时间(5s),Hystrix超时时间>接口响应时间(5s)

  • HTTP_TIMEOUT设置为3s,HYSTRIX_TIMEOUT设置为10s

输出结果:

  • 关于Hystrix超时机制和线程状态的测试观察和个人理解
  • 整个流程为:主线程创建HystrixCommand并执行,Hystrix创建子线程发起http请求,3秒后http请求超时,进入fallback方法。最后主线程收到结果为null。

测试场景3:RestTemplate没有超时,HystrixCommand超时

参数设置:

  • RestTemplate超时时间>接口响应时间(5s),Hystrix超时时间<接口响应时间(5s)

  • HTTP_TIMEOUT设置为10s,HYSTRIX_TIMEOUT设置为3s

输出结果:

  • 关于Hystrix超时机制和线程状态的测试观察和个人理解
  • 整个流程为:主线程创建HystrixCommand并执行,Hystrix创建子线程发起http请求,3秒后Hystrix超时,HystrixTimer线程调用fallback方法。最后主线程收到结果为null。

  • 但注意,这里main方法收到返回结果后,发起http请求的线程在5s后还是收到了请求。也就是说,这里即使HystrixCommand超时结束了,其实际发起请求的子线程并不会结束,即使设置了withExecutionIsolationThreadInterruptOnTimeout(true)也没有用。

底层机制

我参考芋道源码的Hystrix源码解析相关文章,并阅读了Hystrix部分源码后了解到:

HystrixCommand执行过程中,有两个线程,一个是HystrixCommand任务执行线程,一个是等着给HystrixCommand判定超时的线程(HystrixTimer)。当其中一个线程完成自己的逻辑时,会尝试将HystrixCommand的状态置换(CAS),只要任何一个线程对HystrixCommand打上标就意味着超时判定结束。

  • 如果任务执行线程先完成,就会将status设置为completed,超时监听线程在到达超时时间时,发现status已经被标记为完成状态,直接结束。(对应上面的场景1和2)

  • 如果超时监听线程先到达超时时间点,就会将status设置为timeout,此时HystrixCommand会执行fallback中的流程,同时任务执行线程依旧在运行,直到其流程终止。(对应上面的场景3)

流程图

结合底层的原理,对上述三种场景简单地画一下流程图,便于理解:

1.未超时,正常返回
关于Hystrix超时机制和线程状态的测试观察和个人理解
2.任务请求超时
关于Hystrix超时机制和线程状态的测试观察和个人理解
3.HystrixCommand超时

关于Hystrix超时机制和线程状态的测试观察和个人理解资料参考:竽道源码 - Hystrix 源码解析 —— 命令执行(三)之执行超时


长按订阅更多精彩▼

如有收获,点个在看,诚挚感谢