Part2-HttpClient官方教程-Chapter6-HTTP缓存（HTTP Caching）

原文链接

6.1. 一般概念

　　 HttpClient Cache提供了一个与HTTP / 1.1兼容的缓存层与HttpClient（浏览器缓存的Java等价物。）一起使用。该实现遵循责任链设计模式，其中缓存HttpClient实现可以为默认的非缓存HttpClient实现提供一个嵌入式替代; 完全可以从缓存满足的请求不会导致实际的原始请求。 使用条件GET和If-Modified-Since和/或If-None-Match请求标头，过期的缓存条目将尽可能使用原始地址进行自动验证。

　　一般而言，HTTP / 1.1缓存被设计为在语义上是透明的; 也就是说，缓存不应该改变客户端和服务器之间请求 - 响应交换的含义。 因此，将缓存的HttpClient放入现有的兼容客户端 - 服务器关系中应该是安全的。 虽然缓存模块是从HTTP协议的角度来看是客户端的一部分，但实现的目标是与透明缓存代理的要求兼容。

　　最后，缓存HttpClient的包括支持RFC 5861中指定的缓存控制扩展（陈旧-如果误差和陈旧·维持同时重新验证）。

当缓存HttpClient的执行请求时，它经过以下流程：

检查该请求以符合基本的HTTP1.1协议，并尝试修改该请求

刷新将被该请求无效的任何缓存条目。

确定当前请求是否可以从缓存中获取。 如果不是，直接将请求传递给原始服务器，并在适当的情况下缓存后返回响应。

如果它是缓存可加载请求，它将尝试从缓存中读取它。如果它不在缓存中，调用源服务器和缓存响应，如果合适的话。

如果缓存的响应适合作为响应，则构造包含ByteArrayEntity的BasicHttpResponse并将其返回。 否则，尝试对原始服务器重新验证缓存条目。

在无法进行重新验证缓存响应的情况下，调用原始服务器和缓存响应，如果合适的话。

当缓存HttpClient接收响应时，它经过以下流程：

检查响应的协议遵从性

确定响应是否可缓存

如果它是可缓存的，则尝试读取配置中允许的最大大小并将其存储在缓存中。

如果缓存的响应太大，请重新构建部分消耗的响应，并直接返回而不进行缓存。

请注意，缓存HttpClient本身不是HttpClient的不同实现，而是通过将自身作为附加处理组件插入到请求执行管道来工作。（备注：这一句是真的不好翻译）

6.2. RFC-2616 Compliance

　　我们相信HttpClient缓存是无条件符合RFC-2616的。 也就是说，无论规范如何指示：必须、一定不能或者不应该为HTTP缓存，缓存层试图以满足这些要求的方式行事。 这意味着缓存模块在放入时不会产生不正确的行为。

6.3. Example Usage

　　这是如何设置基本缓存HttpClient的简单示例。 按照配置，它将最多存储1000个缓存对象，每个对象的最大主体大小可能为8192字节。 这里选择的数字仅用于举例，并不打算作为规定或考虑为建议。

CacheConfig cacheConfig = CacheConfig.custom()
.setMaxCacheEntries(1000)
.setMaxObjectSize(8192)
.build();
RequestConfig requestConfig = RequestConfig.custom()
.setConnectTimeout(30000)
.setSocketTimeout(30000)
.build();
CloseableHttpClient cachingClient = CachingHttpClients.custom()
.setCacheConfig(cacheConfig)
.setDefaultRequestConfig(requestConfig)
.build();

HttpCacheContext context = HttpCacheContext.create();
HttpGet httpget = new HttpGet("http://www.mydomain.com/content/");
CloseableHttpResponse response = cachingClient.execute(httpget, context);
try {
CacheResponseStatus responseStatus = context.getCacheResponseStatus();
switch (responseStatus) {
case CACHE_HIT:
System.out.println("A response was generated from the cache with " +
"no requests sent upstream");
break;
case CACHE_MODULE_RESPONSE:
System.out.println("The response was generated directly by the " +
"caching module");
break;
case CACHE_MISS:
System.out.println("The response came from an upstream server");
break;
case VALIDATED:
System.out.println("The response was generated from the cache " +
"after validating the entry with the origin server");
break;
}
} finally {
response.close();
}

6.4. 配置（Configuration）

　　缓存HttpClient继承默认非缓存实现的所有配置选项和参数（这包括设置选项，如超时和连接池大小）。 对于特定于缓存的配置，可以提供一个CacheConfig实例来自定义以下行为：

缓冲大小：如果后端存储支持这些限制，则可以指定最大缓存条目数以及最大可缓存响应主体大小。

公/私人缓存：默认情况下，缓存模块认为自己是一个共享（公共）缓存，并且不会缓存对具有“缓存控制：私人”标记的授权头或响应的请求的响应。但是，如果缓存只会通过一个逻辑“用户”使用（类似行为的浏览器缓存），那么你将要关闭共享缓存设置。

启发式缓存：根据RFC2616，即使没有明确的缓存控制头由原始设置，缓存也可以缓存某些缓存条目。这种行为在默认情况下是关闭的，但是如果您正在使用没有设置正确标题但您仍然想要缓存响应的源，则可能需要将其打开。您将希望启用启发式缓存，然后指定自上次修改资源以来的默认新鲜度生存期和/或时间的一小部分。有关启发式缓存的更多详细信息，请参阅HTTP / 1.1 RFC的13.2.2和13.2.4节。

6.5.后端存储（Storage Backends）

　　缓存HttpClient的默认实现将缓存条目和缓存的响应实体存储在应用程序的JVM的内存中。虽然这提供了高性能，但由于大小限制或缓存条目短暂且在应用程序重新启动后无法运行，因此可能不适合您的应用程序。当前版本包括支持使用EhCache和memcached实现来存储缓存条目，这允许将缓存条目溢出到磁盘或将其存储在外部进程中。