当系统用户不断增长时，每个微服务需要承受的并发压力也越来越大，在分布式环境中，通常压力来自对依赖服务的调用，因为亲戚依赖服务的资源需要通过通信来实现，这样的依赖方式比起进程内的调用方式会引起一部分的性能损失，
在高并发的场景下，Hystrix 提供了请求缓存的功能，我们可以方便的开启和使用请求缓存来优化系统，达到减轻高并发时的请求线程消耗、降低请求响应时间的效果
Hystrix的缓存，这个功能是有点鸡肋的，因为这个缓存是基于request的，为什么这么说呢？因为每次请求来之前都必须HystrixRequestContext.initializeContext();进行初始化，
每请求一次controller就会走一次filter，上下文又会初始化一次，前面缓存的就失效了，又得重新来。所以你要是想测试缓存，你得在一次controller请求中多次调用那个加了缓存的service或HystrixCommand命令。
Hystrix的书上写的是：在同一用户请求的上下文中，相同依赖服务的返回数据始终保持一致。在当次请求内对同一个依赖进行重复调用，只会真实调用一次。在当次请求内数据可以保证一致性。
因此。希望大家在这里不要理解错了。
RequestCache主要有三个优点：
在当次请求内对同一个依赖进行重复调用，只会真实调用一次。
在当次请求内数据可以保证一致性。
可以减少不必要的线程开销。
例子还是接着上篇的HelloServiceCommand来进行演示，我们只需要实现HystrixCommand的一个缓存方法名为getCacheKey()即可
代码如下：
/** * Created by cong on 2018/5/9. */ public class HelloServiceCommand extends HystrixCommand<String> { private RestTemplate restTemplate; protected HelloServiceCommand(String commandGroupKey,RestTemplate restTemplate) { super(HystrixCommandGroupKey.Factory.asKey(commandGroupKey)); this.restTemplate = restTemplate; } @Override protected String run() throws Exception { System.out.println(Thread.currentThread().getName()); return restTemplate.getForEntity("",String.class).getBody(); } @Override protected String getFallback() { return "error"; } //Hystrix的缓存 @Override protected String getCacheKey() { //一般动态的取缓存Key,比如userId，这里为了做实验写死了，写为hello return "hello"; } }