为了提高用户体验，增大缓存放大比，同时又要避免客户报障，在做cache时可谓是煞费苦心，大文件、小文件分离，在小文件里又把动态内容和静态内容分离，能存的东西基本上全部存了，唯有动态内容一直没下手，按照之前的策略，动态内容直接代理，1:1的进出，可是
先看一下策略调整后瞬间的流量图：
为了提高用户体验，增大缓存放大比，同时又要避免客户报障，在做cache时可谓是煞费苦心，大文件、小文件分离，在小文件里又把动态内容和静态内容分离，能存的东西基本上全部存了，唯有动态内容一直没下手，按照之前的策略，动态内容直接代理，1:1的进出，可是某些局方就是不消停，非要达到某个放大比，没折了，在动态内容里面动一下刀吧。
在动刀之前，先做分析，对能存的动态内容和ATS的缓存策略做了大量测试，受益匪浅。当前ATS的缓存策略完全按照http协议规定，采用最保守的缓存方式，即只对有明确生命周期缓存头的信息进行存储，动态、cookie、authorization、no-cache一律不存，ats中对应的配置参数就不写了。为了保证质量，直接把带cookie、和授权的动态内容略过了，原因就是风险太大，剩余的有这几类可以尝试：
1、有明确生命周期头的动态url图片等内容；（我们假设网站的头信息是可信的）
2、没有明确头生命周期头的静态url图片、动态url图片等，包括没有任何信息的或只有last-modified头的图片等信息。
对于第1类，很好处理，ats有相应的参数，打开即可：
proxy.config.http.cache.cache_urls_that_look_dynamic INT 1
对于第2类，处理起来，就是个技术活了，首先线上对于头信息的必要条件是：
proxy.config.http.cache.required_headersINT 2
只有放开对这个的限制，才能把第2类给纳括进来，所以把其设置为0是第一必要，设置好后怎么保证其正常服务呢，比如说验证码，他在设置的时候就是没有头信息，保守的策略肯定是正常服务，但这么一放开肯定报障。经分析，ats对于没有头信息内容的缓存时间走的是最大最小缓存时间来确保的，两条时间参数如下:
proxy.config.http.cache.heuristic_min_lifetime INT 3600 proxy.config.http.cache.heuristic_max_lifetime INT 864000
对于只有last-modified头的信息是通过老化因子计算出来的，老化因子参数如下：
proxy.config.http.cache.heuristic_lm_factor-v 0.1
于是想出主意，内容来后通存，但每次吐之前让ATS发一个IMS头信息给源站询问是否有变化，由于这个头信息只是询问，不会占用多少流量，如果没有变化就TCP_REFRESH_HIT吐给用户，虽然回源了，但是内容还是从缓存中吐出去的，如果有变化那就TCP_REFRESH_MISS吐给用户，用户拿到的同样是最新内容，这样无形中会增加一部分吐流。
可是参数怎么设置呢？突然想到我可以把上面的参数都设置为0，理论上就达到了我的目的，第一次存下来，从第二次开始就IMS头回源询问，马上找测试环境测试，果然跟料想的一样，兴奋之余立马把策略更新到线上，通过流量图工具监控了一小时，回源总体是有所减少了，不过也发生了奇怪的事儿，用tsar看某些时刻的回源还是和吐的差不多，而且用traffic_logstats -s分析后发现有很多的ERR_CLIENT_ABORT,真是要命，这个日志是客户端连接后数据还没接收完就主动断开了连接，少是正常的，多的话就有问题了，我找了个1M带有max-age的图片做测试，先purge一下，然后curl连接一下马上断开，制造这个错误日志，第二次访问，竟然是TCP_HIT,下载到本地图片正常打开，要命啊，原来ATS在处理这种问题时会继续下载到cache里面去，因为这批域名质量本就差，所以造成回源流量时而还是很高，继续想办法google上找资料，找到了这条参数：
proxy.config.http.background_fill_completed_thresholdFLOAT 0.5
默认是设置为0的，这个参数的意思是客户端突然断开，下载到百分之多少时会继续下载，否则就会断开，没有多加考虑，设置为0.5，做了测试，然后马上更新上去，流量稳定了，吞吐量也上升了。
终于算是一个小圆满，并不是线上的参数就这么稳定了，后续根据业务情况还是需要调整测试的的，不过这也是乐趣所在吧。
所有的调整是一个平衡，当前的调整：1、增加了磁盘读写IO；2、增加了cpu的负载。
 |
社长"矢量比特"，曾就职中软、新浪，现任职小米，致力于DevOps运维体系的探索和运维技术的研究实践. |
