Hystrix 请求缓存的使用

 

总括：

 

Hystrix有两种方式来应对高并发场景，分别是请求缓存与请求合并

 

 

 

 

请求缓存是在同一请求（controller）多次访问中保证只调用一次这个服务提供者的接口（service），在这同一次请求第一次的结果会被缓存，保证同一请求中同样的多次访问返回结果相同

请求缓存不是只写入一次结果就不再变化的，而是每次请求到达Controller的时候，我们都需要为HystrixRequestContext进行初始化（每次执行完成请求就刷新缓存），之前的缓存也就是不存在了，我们是在同一个请求中保证结果相同，同一次请求中的第一次访问后对结果进行缓存，

缓存的生命周期只有一次请求！----这种缓存刷新的特性不同于redis，redis的cacheable,cacheput,cacheevict是一次请求永久有效

 

 

 

 

一：所有需要使用hystrix的方法，都会根据注解生成代理类---继承HystrixCommand，代理类中取实现，

 

二：不是一般性的功能使用都是1，开启注解，2，使用注解

使用Filter方式：

1，在启动类加入@ServletComponentScan注解

 

2，@WebFilter(filterName = "hystrixRequestContextServletFilter",urlPatterns = "/*",asyncSupported = true)

 

可以用于过滤或者解决一些需要提前初始化问题：HystrixRequestContext 未初始化

 

 

熔断及其缓存的注解放在service层：

 

@CacheResult(cacheKeyMethod= getCacheKey---以参数加工作为key的函数==@CacheKey

 

 public String getCacheKey(Long id){

        return String.valueOf(id);

    }

 

 

 @HystrixCommand(commandKey = "commandKey1")

 

 

 

 

commandKey  和  CacheKey 需要联合使用  才能实现缓存相关功能例如：

 

 

放在需要使用的方法上，调用就生效：

增加缓存：

 

 

 

@CacheResult(cacheKeyMethod = "getCacheKey")

    @HystrixCommand(commandKey = "commandKey1")

 

 

 

 

删除缓存：

@CacheRemove(commandKey = "commandKey1", cacheKeyMethod = "getCacheKey")

 

 

 

 public String getCacheKey(Long id){

        return String.valueOf(id);

    }

 

 

 

cachekey的三种指定方式：

1，cachekeymethod---指定生成key的方式---一般用参数加工

2，直接用@cachekey 一般放在参数前----使用所有参数作为key

3,没有写就是默认用所有的参数作为key

 

 

示例：

前言：

---

最近忙着微服务项目的开发，脱更了半个月多，今天项目的初版已经完成，所以打算继续我们的微服务学习，由于Hystrix这一块东西好多，只好多拆分几篇文章写，对于一般对性能要求不是很高的项目中，可以使用其基础上开发的Feign进行容错保护。Hystrix学到现在我认为它的好处在于可以更灵活的调整熔断时间和自定义的线程隔离策略，设置请求缓存与请求合并，还可以降低被调用服务的负载，配合仪表盘和Turbine进行服务状态监控等，更加深入的还请阅读书籍，理解浅薄，还望看官莫笑。 由于篇幅有限，请求合并的使用放在下一篇博客中

本文主要浅析Hystrix的请求缓存的使用

前情提要：

---

之前我们学习了自定义HystrixCommand，包括继承和注解两种方式实现了同步请求和异步请求，也正是这里我们开始使用了整个的项目管理我们的代码，防止了项目过于分散丢笔记的情况。

如果是和我一样在搭建并测试的，请来Github clone我的项目，地址是：https://github.com/HellxZ/SpringCloudLearn 欢迎大家对这个项目提建议。

正文：

---

在高并发的场景中，消费者A调用提供者B，如果请求是相同的，那么重复请求势必会加重服务提供者B的负载，一般我们做高并发场景会理所应当的想到用缓存，那么针对这种情况Hystrix有什么方式来应对么？

Hystrix有两种方式来应对高并发场景，分别是请求缓存与请求合并

回顾一下我们前几篇文章中搭建的服务提供者项目，它会在有请求过来的时候打印此方法被调用。为了这次的测试，我们先在服务提供者项目中提供一个返回随机数的接口，作为测试请求缓存的调用的接口，方便验证我们的看法。

在EurekaServiceProvider项目中的GetRequestController中添加如下方法

    /**
     * 为了请求测试Hystrix请求缓存提供的返回随机数的接口
     */
    @GetMapping("/hystrix/cache")
    public Integer getRandomInteger(){
        Random random = new Random();
        int randomInt = random.nextInt(99999);
        return randomInt;
    }

注意：以下有些注释写的很清楚的地方，就不重复写了

接下来我们先介绍请求缓存

请求缓存

请求缓存是在同一请求多次访问中保证只调用一次这个服务提供者的接口，在这同一次请求第一次的结果会被缓存，保证同一请求中同样的多次访问返回结果相同。

PS：在写这篇文章之前，本人将Hystrix与Redis进行了类比，后来证明我是理解错了。在认识到问题的情况下，我又重新为这篇文章重写了正确的代码

正解：请求缓存不是只写入一次结果就不再变化的，而是每次请求到达Controller的时候，我们都需要为HystrixRequestContext进行初始化，之前的缓存也就是不存在了，我们是在同一个请求中保证结果相同，同一次请求中的第一次访问后对结果进行缓存，缓存的生命周期只有一次请求！

这里分别介绍使用继承和使用注解两种方式，这里使用前文用到的RibbonConsumHystix项目

1. 1继承方式

1.1.1 开启请求缓存 与 清除请求缓存

在com.cnblogs.hellxz.hystrix包下，因为和UserCommand类中的返回值不同，为了不破坏已有代码，我们在hystrix新建一个CacheCommand类，如下：

package com.cnblogs.hellxz.hystrix;

import com.netflix.hystrix.HystrixCommand;
import com.netflix.hystrix.HystrixCommandKey;
import com.netflix.hystrix.HystrixRequestCache;
import com.netflix.hystrix.strategy.concurrency.HystrixConcurrencyStrategyDefault;
import org.springframework.web.client.RestTemplate;

/**
 * <p><b>描    述</b>: 请求缓存HystrixCommand</p>
 *
 * <p><b>创建日期</b> 2018/5/18 10:26 </p>
 *
 * @author HELLXZ 张
 * @version 1.0
 * @since jdk 1.8
 */
public class CacheCommand extends HystrixCommand<Integer> {


    private RestTemplate restTemplate;
    private static Long id;

    public CacheCommand(Setter setter, RestTemplate restTemplate, Long id){
        super(setter);
        this.restTemplate = restTemplate;
        this.id = id;
    }

    /**
     * 这里我们调用产生随机数的接口
     */
    @Override
    protected Integer run() throws Exception {
        return restTemplate.getForObject("http://eureka-service/hystrix/cache",Integer.class);
    }

    /**
     * 开启请求缓存，只需重载getCacheKey方法
     * 因为我们这里使用的是id，不同的请求来请求的时候会有不同cacheKey所以，同一请求第一次访问会调用，之后都会走缓存
     * 好处：    1.减少请求数、降低并发
     *          2.同一用户上下文数据一致
     *          3.这个方法会在run()和contruct()方法之前执行，减少线程开支
     */
    @Override
    public String getCacheKey() {
        return String.valueOf(id); //这不是唯一的方法，可自定义，保证同一请求返回同一值即可
    }

    /**
     * 清理缓存
     * 开启请求缓存之后，我们在读的过程中没有问题，但是我们如果是写，那么我们继续读之前的缓存了
     * 我们需要把之前的cache清掉
     * 说明 ：   1.其中getInstance方法中的第一个参数的key名称要与实际相同
     *          2.clear方法中的cacheKey要与getCacheKey方法生成的key方法相同
     *          3.注意我们用了commandKey是test,大家要注意之后new这个Command的时候要指定相同的commandKey,否则会清除不成功
     */
    public static void flushRequestCache(Long id){
        HystrixRequestCache.getInstance(
                HystrixCommandKey.Factory.asKey("test"), HystrixConcurrencyStrategyDefault.getInstance())
                .clear(String.valueOf(id));
    }

    public static Long getId() {
        return id;
    }

}

说明一下，使用继承的方式，只需要重写getCacheKey()，有了开启缓存自然有清除缓存的方法，用以确保我们在同一请求中进行写操作后，让后续的读操作获取最新的结果，而不是过时的结果。

需要注意的地方：

1.flushRequestCache(Long id)，其中.clear()中的cacheKey的生成方法相同，只有把正确需要清除的key清掉才会连同value一同清掉，从而达到清除缓存的作用。

2.清除缓存时机：我们应该在同一个Controller中进行写操作之后，如果这个操作之后还有访问同一资源的请求，那么必须加清除缓存，从而保证数据同步，如果后面没有读操作，无须清除缓存，因为在下一次请求到来的时候HystrixRequestContext会重置，缓存自然也没有了

为了更好的演示，这里扩充一下RibbonService，添加如下代码：

    /**
     * 继承方式开启请求缓存,注意commandKey必须与清除的commandKey一致
     */
    public void openCacheByExtends(){
        CacheCommand command1 = new CacheCommand(com.netflix.hystrix.HystrixCommand.Setter.withGroupKey(
                                                                            HystrixCommandGroupKey.Factory.asKey("group")).andCommandKey(HystrixCommandKey.Factory.asKey("test")),
                                                                        restTemplate,1L);
        CacheCommand command2 = new CacheCommand(com.netflix.hystrix.HystrixCommand.Setter.withGroupKey(
                                                                            HystrixCommandGroupKey.Factory.asKey("group")).andCommandKey(HystrixCommandKey.Factory.asKey("test")),
                                                                        restTemplate,1L);
        Integer result1 = command1.execute();
        Integer result2 = command2.execute();
        LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
    }

    /**
     * 继承方式清除请除缓存
     */
    public void clearCacheByExtends(){
        CacheCommand.flushRequestCache(1L);
        LOGGER.info("请求缓存已清空！");
    }

在RibbonController添加如下代码，设计实验：

    /**
     * 继承方式开启请求缓存,并多次调用CacheCommand的方法
     * 在两次请求之间加入清除缓存的方法
     */
    @GetMapping("/cacheOn")
    public void openCacheTest(){
        //初始化Hystrix请求上下文
        HystrixRequestContext.initializeContext();
        //开启请求缓存并测试两次
        service.openCacheByExtends();
        //清除缓存
        service.clearCacheByExtends();
        //再次开启请求缓存并测试两次
        service.openCacheByExtends();
    }

注意：之前说过，每次Controller被访问的时候，Hystrix请求的上下文都需要被初始化，这里可以用这种方式作测试，但是生产环境是用filter的方式初始化的，这种方式放到请求缓存的结尾讲

分别启动注册中心、服务提供者、RibbonConsumHystrix（当前项目）

使用postman get 请求访问：http://localhost:8088/hystrix/cacheOn

我们会看到有以下输出：

2018-05-18 12:41:42.274  INFO 1288 --- [nio-8088-exec-1] c.cnblogs.hellxz.servcie.RibbonService   : first request result is:63829 ,and secend request result is: 63829
2018-05-18 12:41:42.274  INFO 1288 --- [nio-8088-exec-1] c.cnblogs.hellxz.servcie.RibbonService   : 请求缓存已清空！
2018-05-18 12:41:42.281  INFO 1288 --- [nio-8088-exec-1] c.cnblogs.hellxz.servcie.RibbonService   : first request result is:65775 ,and secend request result is: 65775

达到目的，接下来我们讲讲注解的方式！

1.2 注解方式

继承方式自然没有注解开发快而且省力，想必大家期待已久了，在此之前我们需要了解三个注解：

注解 描述 属性

@CacheResult	该注解用来标记请求命令返回的结果应该被缓存，它必须与@HystrixCommand注解结合使用	cacheKeyMethod
@CacheRemove	该注解用来让请求命令的缓存失效，失效的缓存根据commandKey进行查找。	commandKey,cacheKeyMethod
@CacheKey	该注解用来在请求命令的参数上标记，使其作为cacheKey，如果没有使用此注解则会使用所有参数列表中的参数作为cacheKey	value

本人实测总结三种注解方式均可用，实现大同小异，与大家分享之

1.2.1 方式1 :使用getCacheKey方法获取cacheKey

扩充RibbonService

    /**
     * 使用注解请求缓存 方式1
     * @CacheResult  标记这是一个缓存方法，结果会被缓存
     */
    @CacheResult(cacheKeyMethod = "getCacheKey")
    @HystrixCommand(commandKey = "commandKey1")
    public Integer openCacheByAnnotation1(Long id){
        //此次结果会被缓存
        return restTemplate.getForObject("http://eureka-service/hystrix/cache", Integer.class);
    }

    /**
     * 使用注解清除缓存 方式1
     * @CacheRemove 必须指定commandKey才能进行清除指定缓存
     */
    @CacheRemove(commandKey = "commandKey1", cacheKeyMethod = "getCacheKey")
    @HystrixCommand
    public void flushCacheByAnnotation1(Long id){
        LOGGER.info("请求缓存已清空！");
        //这个@CacheRemove注解直接用在更新方法上效果更好
    }

    /**
     * 第一种方法没有使用@CacheKey注解，而是使用这个方法进行生成cacheKey的替换办法
     * 这里有两点要特别注意：
     * 1、这个方法的入参的类型必须与缓存方法的入参类型相同，如果不同被调用会报这个方法找不到的异常
     * 2、这个方法的返回值一定是String类型
     */
    public String getCacheKey(Long id){
        return String.valueOf(id);
    }

扩充RibbonController

    /**
     * 注解方式请求缓存，第一种
     */
    @GetMapping("/cacheAnnotation1")
    public void openCacheByAnnotation1(){
        //初始化Hystrix请求上下文
        HystrixRequestContext.initializeContext();
        //访问并开启缓存
        Integer result1 = service.openCacheByAnnotation1(1L);
        Integer result2 = service.openCacheByAnnotation1(1L);
        LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
        //清除缓存
        service.flushCacheByAnnotation1(1L);
        //再一次访问并开启缓存
        Integer result3 = service.openCacheByAnnotation1(1L);
        Integer result4 = service.openCacheByAnnotation1(1L);
        LOGGER.info("first request result is:{} ,and secend request result is: {}", result3, result4);
    }

测试

使用postman get 请求访问 http://localhost:8088/hystrix/cacheAnnotation1

查看输出

2018-05-18 15:39:11.971  INFO 4180 --- [nio-8088-exec-5] o.s.web.bind.annotation.RestController   : first request result is:59020 ,and secend request result is: 59020
2018-05-18 15:39:11.972  INFO 4180 --- [ibbonService-10] c.cnblogs.hellxz.servcie.RibbonService   : 请求缓存已清空！
2018-05-18 15:39:11.979  INFO 4180 --- [nio-8088-exec-5] o.s.web.bind.annotation.RestController   : first request result is:51988 ,and secend request result is: 51988

测试通过！

1.2.2 方式2 :使用@CacheKey指定cacheKey

扩充RibbonService

    /**
     * 使用注解请求缓存 方式2
     * @CacheResult  标记这是一个缓存方法，结果会被缓存
     * @CacheKey 使用这个注解会把最近的参数作为cacheKey
     *
     * 注意：有些教程中说使用这个可以指定参数，比如：@CacheKey("id") , 但是我这么用会报错，网上只找到一个也出这个错误的贴子没解决
     *          而且我发现有一个问题是有些文章中有提到 “不使用@CacheResult，只使用@CacheKey也能实现缓存” ，经本人实测无用
     */
    @CacheResult
    @HystrixCommand(commandKey = "commandKey2")
    public Integer openCacheByAnnotation2(@CacheKey Long id){
        //此次结果会被缓存
        return restTemplate.getForObject("http://eureka-service/hystrix/cache", Integer.class);
    }

    /**
     * 使用注解清除缓存 方式2
     * @CacheRemove 必须指定commandKey才能进行清除指定缓存
     */
    @CacheRemove(commandKey = "commandKey2")
    @HystrixCommand
    public void flushCacheByAnnotation2(@CacheKey Long id){
        LOGGER.info("请求缓存已清空！");
        //这个@CacheRemove注解直接用在更新方法上效果更好
    }

扩充RibbonController

    /**
     * 注解方式请求缓存，第二种
     */
    @GetMapping("/cacheAnnotation2")
    public void openCacheByAnnotation2(){
        //初始化Hystrix请求上下文
        HystrixRequestContext.initializeContext();
        //访问并开启缓存
        Integer result1 = service.openCacheByAnnotation2(2L);
        Integer result2 = service.openCacheByAnnotation2(2L);
        LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
        //清除缓存
        service.flushCacheByAnnotation2(2L);
        //再一次访问并开启缓存
        Integer result3 = service.openCacheByAnnotation2(2L);
        Integer result4 = service.openCacheByAnnotation2(2L);
        LOGGER.info("first request result is:{} ,and secend request result is: {}", result3, result4);
    }

测试

使用postman get 请求访问 http://localhost:8088/hystrix/cacheAnnotation2

查看输出

2018-05-18 15:40:49.803  INFO 4180 --- [nio-8088-exec-6] o.s.web.bind.annotation.RestController   : first request result is:47604 ,and secend request result is: 47604
2018-05-18 15:40:49.804  INFO 4180 --- [ibbonService-10] c.cnblogs.hellxz.servcie.RibbonService   : 请求缓存已清空！
2018-05-18 15:40:49.809  INFO 4180 --- [nio-8088-exec-6] o.s.web.bind.annotation.RestController   : first request result is:34083 ,and secend request result is: 34083

测试通过！

1.2.3 方式3 :使用默认所有参数作为cacheKey

扩充RibbonService

    /**
     * 使用注解请求缓存 方式3
     * @CacheResult  标记这是一个缓存方法，结果会被缓存
     * @CacheKey 使用这个注解会把最近的参数作为cacheKey
     *
     * 注意：有些教程中说使用这个可以指定参数，比如：@CacheKey("id") , 但是我这么用会报错，网上只找到一个也出这个错误的贴子没解决
     *          而且我发现有一个问题是有些文章中有提到 “不使用@CacheResult，只使用@CacheKey也能实现缓存” ，经本人实测无用
     */
    @CacheResult
    @HystrixCommand(commandKey = "commandKey3")
    public Integer openCacheByAnnotation3(Long id){
        //此次结果会被缓存
        return restTemplate.getForObject("http://eureka-service/hystrix/cache", Integer.class);
    }

    /**
     * 使用注解清除缓存 方式3
     * @CacheRemove 必须指定commandKey才能进行清除指定缓存
     */
    @CacheRemove(commandKey = "commandKey3")
    @HystrixCommand
    public void flushCacheByAnnotation3(Long id){
        LOGGER.info("请求缓存已清空！");
        //这个@CacheRemove注解直接用在更新方法上效果更好
    }

扩充RibbonController

    /**
     * 注解方式请求缓存，第三种
     */
    @GetMapping("/cacheAnnotation3")
    public void openCacheByAnnotation3(){
        //初始化Hystrix请求上下文
        HystrixRequestContext.initializeContext();
        //访问并开启缓存
        Integer result1 = service.openCacheByAnnotation3(3L);
        Integer result2 = service.openCacheByAnnotation3(3L);
        LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
        //清除缓存
        service.flushCacheByAnnotation3(3L);
        //再一次访问并开启缓存
        Integer result3 = service.openCacheByAnnotation3(3L);
        Integer result4 = service.openCacheByAnnotation3(3L);
        LOGGER.info("first request result is:{} ,and secend request result is: {}", result3, result4);
    }

测试

使用postman get 请求访问 http://localhost:8088/hystrix/cacheAnnotation3

查看输出

2018-05-18 15:41:19.655  INFO 4180 --- [nio-8088-exec-8] o.s.web.bind.annotation.RestController   : first request result is:24534 ,and secend request result is: 24534
2018-05-18 15:41:19.656  INFO 4180 --- [ibbonService-10] c.cnblogs.hellxz.servcie.RibbonService   : 请求缓存已清空！
2018-05-18 15:41:19.662  INFO 4180 --- [nio-8088-exec-8] o.s.web.bind.annotation.RestController   : first request result is:85409 ,and secend request result is: 85409

测试通过！

1.4 出现的问题

1.4.1 HystrixRequestContext 未初始化

2018-05-17 16:57:22.759 ERROR 5984 --- [nio-8088-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.netflix.hystrix.exception.HystrixRuntimeException: UserCommand failed while executing.] with root cause

java.lang.IllegalStateException: Request caching is not available. Maybe you need to initialize the HystrixRequestContext?
    at com.netflix.hystrix.HystrixRequestCache.get(HystrixRequestCache.java:104) ~[hystrix-core-1.5.12.jar:1.5.12]
……省略多余输出……

初始化HystrixRequestContext方法：

两种方法

1、在每个用到请求缓存的Controller方法的第一行加上如下代码：

        //初始化Hystrix请求上下文
        HystrixRequestContext context = HystrixRequestContext.initializeContext();
        //省略中间代码上下文环境用完需要关闭
        context.close();

2、使用Filter方式：

在启动类加入@ServletComponentScan注解

在con.cnblogs.hellxz.filter包下创建HystrixRequestContextServletFilter.java，实现Filter接口，在doFilter方法中添加方法1中的那一行代码，并在一次请求结束后关掉这个上下文

package com.cnblogs.hellxz.filter;

import com.netflix.hystrix.strategy.concurrency.HystrixRequestContext;
import javax.servlet.*;
import javax.servlet.annotation.WebFilter;
import java.io.IOException;

/**
 * <b>类名</b>: HystrixRequestContextServletFilter
 * <p><b>描    述</b>: 实现Filter用于初始化Hystrix请求上下文环境</p>
 *
 * <p><b>创建日期</b>2018/5/18 16:13</p>
 * @author HELLXZ 张
 * @version 1.0
 * @since jdk 1.8
 */
@WebFilter(filterName = "hystrixRequestContextServletFilter",urlPatterns = "/*",asyncSupported = true)
public class HystrixRequestContextServletFilter implements Filter {
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        //初始化Hystrix请求上下文
        HystrixRequestContext context = HystrixRequestContext.initializeContext();
        try {
            //请求正常通过
            chain.doFilter(request, response);
        } finally {
            //关闭Hystrix请求上下文
            context.shutdown();
        }
    }

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {

    }

    @Override
    public void destroy() {

    }
}

此时注释掉RibbonController中每个Controller方法中的HystrixRequestContext.initializeContext();（不注掉也没事）

重启RibbonConsumHystrix项目，访问其中用到请求缓存的接口http://localhost:8088/hystrix/cacheAnnotation1

查看输出

2018-05-18 16:17:36.002  INFO 7268 --- [nio-8088-exec-4] o.s.web.bind.annotation.RestController   : first request result is:35329 ,and secend request result is: 35329
2018-05-18 16:17:36.005  INFO 7268 --- [RibbonService-8] c.cnblogs.hellxz.servcie.RibbonService   : 请求缓存已清空！
2018-05-18 16:17:36.013  INFO 7268 --- [nio-8088-exec-4] o.s.web.bind.annotation.RestController   : first request result is:88678 ,and secend request result is: 88678

一切正常！

结语

---

通过这篇文章我们学习了Hystrix的请求缓存的使用，在写本文过程中纠正了很多只看书学到的错误知识，并不是说书中写错了，可能是spring cloud的不同版本所造成的问题，所以，学习还是推荐大家动手实践。受限于篇幅的限制，本来是想把请求合并一并写出来的，想了下暂时请求合并的代码我还没有测试通过，所以，综上所述，请求合并部分，我会在下篇文章中写。可能不会快，但一定会有。

 

 

参考：

https://www.cnblogs.com/hellxz/p/9056806.html