转载

httpClient4.2官方文档研究(8)第7章

第七章

7. HTTP缓存

7.1.一般概念

HttpClient的Cache提供一个使用HttpClient的遵守HTTP/1.1缓存层 - 相当于Java中的浏览器缓存。实现如下的Decorator设计模式，，其中CachingHttpClient类是一个DefaultHttpClient下降的替代品，完全能满足从缓存中的请求将不会导致在实际的原产地请求。陈旧的缓存条目会被自动验证的原产地在可能的情况下，使用条件获取，如果无匹配的If-Modified-Since和/或请求标头。

HTTP/1.1一般被设计为语义透明的缓存，缓存不应该改变客户端和服务器之间的请求响应交换的意义。因此，它应该是安全的，掉了CachingHttpClient到现有的兼容的客户端 - 服务器关系。虽然缓存模块的一部分的客户端从一个HTTP协议的角度来看，实施的目的是放在一个透明的缓存代理的要求兼容。

最后，CachingHttpClient包括支持由RFC 5861（过时 - 如果错误和过时的同时，重新验证）指定的Cache-Control扩展。

当CachingHttpClient执行请求时，它会通过以下流程：

检查的要求基本符合HTTP 1.1协议，并试图纠正的要求。

清除高速缓存条目这将是无效的申请。

确定是否将当前请求servable从缓存。如果没有，直接通过要求到源服务器返回响应后，高速缓存，如果适当。

如果是AA的高速缓存servable要求的，它会尝试从缓存中读取。如果没有在缓存中，请在原服务器和缓存响应，如果合适的话。

如果缓存的响应是适合担任响应中，构建BasicHttpResponse含有一个ByteArrayEntity，并返回它。否则，尝试对原始服务器重新验证缓存条目。

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

当CachingHttpClient收到响应时，它会通过以下流程：

检查的响应协议符合

确定是否响应是可缓存

如果是高速缓存，尝试读取配置中允许的最大尺寸，并将其存储在高速缓存中。

如果反应过大的缓存，重建部分消耗的响应和没有缓存，它直接返回。

重要的是要注意的，CachingHttpClient是没有，本身一个HttpClient的实施，但是，它装饰的HttpClient的实现的一个实例。如果你不提供一个实现，它会使用DefaultHttpClient内部默认情况下。

7.2.符合RFC-2616标准

HttpClient的缓存作出努力至少有条件符合RFC-2616。也就是说，只要规范表示必须或不能为HTTP缓存，缓存层试图表现的方式满足这些要求。这意味着缓存模块不会产生不正确的行为，当你放下它。同时，该项目将继续无条件地遵守，这将增加符合所有应有的忘我，其中许多我们已经符合与。我们不能要求完全无条件地遵守，直到我们所有的人都满意。

7.3.用法示例

这是一个简单的例子，如何建立一个基本的CachingHttpClient。至于配置方面，它最多可存储1000缓存的对象，每一个可能有一个最大的车身尺寸为8192字节。例如这里选择的数字，而不是只旨在规范或作为建议考虑。

CacheConfig cacheConfig = new CacheConfig();   cacheConfig.setMaxCacheEntries(1000); cacheConfig.setMaxObjectSizeBytes(8192);  HttpClient cachingClient = new CachingHttpClient(new DefaultHttpClient(), cacheConfig);  HttpContext localContext = new BasicHttpContext(); HttpGet httpget = new HttpGet("http://www.mydomain.com/content/"); HttpResponse response = cachingClient.execute(httpget, localContext); HttpEntity entity = response.getEntity(); EntityUtils.consume(entity); CacheResponseStatus responseStatus = (CacheResponseStatus) localContext.getAttribute(         CachingHttpClient.CACHE_RESPONSE_STATUS); 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; }

7.4.组态

由于CachingHttpClient是一个装饰，多的配置，您可能希望这样做可以做到在使用HttpClient的“后端”的HttpClient（包括设置选项，如超时和连接池的大小）。缓存特定的配置，你可以提供一个CacheConfig例如到全面定制行为在以下几个方面：

缓存的大小。如果后端存储支持这些限制，您可以指定最大高速缓存条目数以及最大可缓存响应的机身尺寸。

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

启发式caching.Per RFC2616，高速缓存可以缓存一定的缓存项，即使没有明确的缓存控制头设置的原点。此行为是默认关闭的，但你可能要打开这个选项，如果你正在使用的原产地不设置适当的标头，但你还是要缓存的响应。您将要，使启发式高速缓存，然后指定一个默认的新鲜寿命和/或短的时间内，由于资源的最后修改。启发式缓存的详细信息，请参阅第13.2.2和13.2.4对HTTP/1.1 RFC。

背景验证。高速缓存模块支持RFC5861，它允许一定的缓存条目重新甄审的背景发生在陈旧的指令时重新验证。您可能需要调整设置的后台工作线程的最小和最大数目，以及他们在回收之前可以闲置的最大时间。您还可以控制大小的用于重新甄审的队列时没有足够的工人跟上需求。

7.5.存储后端

默认实现CachingHttpClient高速缓存条目存储在您的应用程序在JVM的内存和缓存的响应机构。提供高性能，它可能不适合您的应用程序的限制大小或，因为缓存条目是短暂的，没有生存重新启动应用程序。目前的版本包括支持使用Ehcache和memcached的实现，它允许为溢出到磁盘高速缓存条目，或将它们存储在外部进程中的存储高速缓存条目。

如果没有这些选项适用于您的应用程序，它可以提供自己的存储后端实施的HttpCacheStorage的接口，然后提供，到CachingHttpClient在施工时间。在这种情况下，高速缓存条目将被存储使用你的计划，但你会得到重用周围HTTP/1.1合规性和缓存处理，所有的逻辑。一般来说，它应该是可以，创建一个HttpCacheStorage实现的东西，支持一键/值存储（类似于Java的Map接口）的能力，适用于原子更新。

最后，因为在CachingHttpClient是一个装饰为HttpClient的，它完全有可能成立一个多层次的缓存层次结构，例如，包装一个内存中的CachingHttpClient周围，存储高速缓存条目的磁盘或远程memcached中，类似的模式虚拟内存，L1/L2处理器，缓存等。

正文到此结束