《Squid 中文权威指南》第7章 译者：彭勇华

cache_replacement_policy指令控制了squid的磁盘cache的置换策略。Squid2.5版本提供了三种不同的置换策略：最少近来使用（LRU），贪婪对偶大小次数（GDSF），和动态衰老最少经常使用（LFUDA)。

LRU是默认的策略，并非对squid，对其他大部分cache产品都是这样。LRU是流行的选择，因为它容易执行，并提供了非常好的性能。在32位系统上，LRU相对于其他使用更少的内存（每目标12对16字节）。在64位系统上，所有的策略每目标使用24字节。

在过去，许多研究者已经提议选择LRU。其他策略典型的被设计来改善cache的其他特性，例如响应时间，命中率，或字节命中率。然而研究者的改进结果也可能在误导人。某些研究使用并不现实的小cache目标；其他研究显示当cache大小增加时，置换策略的选择变得不那么重要。

假如你想使用GDSF或LFUDA策略，你必须在./configure时使用--enable-removal-policies选项（见3.4.1章）。Martin Arlitt和HP实验室的John Dilley为squid写了GDSF和LFUDA算法。你可以在线阅读他们的文档：
http://www.hpl.hp.com/techreports/1999/HPL-1999-69.html 

我在O'Reilly出版的书"Web Caching"，也讨论了这些算法。

cache_replacement_policy指令的值是唯一的，这点很重要。不象squid.conf里的大部分其他指令，这个指令的位置很重要。cache_replacement_policy指令的值在squid解析cache_dir指令时，被实际用到。通过预先设置替换策略，你可以改变cache_dir的替换策略。例如：
cache_replacement_policy lru
cache_dir ufs /cache0 2000 16 32
cache_dir ufs /cache1 2000 16 32

cache_replacement_policy heap GDSF
cache_dir ufs /cache2 2000 16 32
cache_dir ufs /cache3 2000 16 32

在该情形中，头2个cache目录使用LRU置换策略，接下来2个cache目录使用GDSF。请记住，假如你已决定使用cache管理器的config选项（见14.2.1.7章），这个置换策略指令的特性就非常重要。cache管理器仅仅输出最后一个置换策略的值，将它置于所有的cache目录之前。例如，你可能在squid.conf里有如下行：
cache_replacement_policy heap GDSF
cache_dir ufs /tmp/cache1 10 4 4
cache_replacement_policy lru
cache_dir ufs /tmp/cache2 10 4 4

但当你从cache管理器选择config时，你得到：
cache_replacement_policy lru
cache_dir ufs /tmp/cache1 10 4 4
cache_dir ufs /tmp/cache2 10 4 4

就象你看到的一样，对头2个cache目录的heap GDSF设置被丢失了。

7.6 删除缓存对象

在某些情况下，你必须从squid的cache里手工删除一个或多个对象。这些情况可能包括：
+ 你的用户抱怨总接收到过时的数据；
+ 你的cache因为某个响应而“中毒”；
+ Squid的cache索引在经历磁盘I/O错误或频繁的crash和重启后，变得有问题；
+ 你想删除一些大目标来释放空间给新的数据；
+ Squid总从本地服务器中cache响应，现在你不想它这样做。

上述问题中的一些可以通过强迫web浏览器reload来解决。然而，这并非总是可靠。例如，一些浏览器通过载入另外的程序，从而显示某些类容类型；那个程序可能没有reload按钮，或甚至它了解cache的情况。

假如必要，你总可以使用squidclient程序来reload缓存目标。简单的在uri前面使用-r选项：
% squidclient -r http://www.lrrr.org/junk >;/tmp/foo

假如你碰巧在refresh_pattern指令里设置了ignore-reload选项，你和你的用户将不能强迫缓存响应更新。在这样的情形下，你最好清除这些有错误的缓存对象。

7.6.1 删除个别对象

Squid接受一种客户请求方式，用于删除cache对象。PURGE方式并非官方HTTP请求方式之一。它与DELETE不同，对后者，squid将其转发到原始服务器。PURGE请求要求squid删除在uri里提交的目标。squid返回200（OK）或404（Not Found）。

PURGE方式某种程度上有点危险，因为它删除了cache目标。除非你定义了相应的ACL，否则squid禁止PURGE方式。正常的，你仅仅允许来自本机和少数可信任主机的PURGE请求。配置看起来如下：
acl AdminBoxes src 127.0.0.1 172.16.0.1 192.168.0.1
acl Purge method PURGE

http_access allow AdminBoxes Purge
http_access deny Purge

squidclient程序提供了产生PURGE请求的容易方法，如下：
% squidclient -m PURGE http://www.lrrr.org/junk

代替的，你可以使用其他工具（例如perl脚本）来产生你自己的HTTP请求。它非常简单：
PURGE http://www.lrrr.org/junk HTTP/1.0
Accept: */*

注意某个单独的URI不唯一标明一个缓存响应。Squid也在cache关键字里使用原始请求方式。假如响应包含了不同的头部，它也可以使用其他请求头。当你发布PURGE请求时，Squid使用GET和HEAD的原始请求方式来查找缓存目标。而且，Squid会删除响应里的所有variants，除非你在PURGE请求的相应头部里指定了要删除的variants。Squid仅仅删除GET和HEAD请求的variants。

7.6.2 删除一组对象

不幸的是，Squid没有提供一个好的机制，用以立刻删除一组对象。这种要求通常出现在某人想删除所有属于同一台原始服务器的对象时。

因为很多理由，squid不提供这种功能。首先，squid必须遍历所有缓存对象，执行线性搜索，这很耗费CPU，并且耗时较长。当squid在搜索时，用户会面临性能下降问题。第二，squid在内存里对URI保持MD5算法，MD5是单向哈希，这意味着，例如，你不能确认是否某个给定的MD5哈希是由包含"www.example.com"字符串的URI产生而来。唯一的方法是从原始URI重新计算MD5值，并且看它们是否匹配。因为squid没有保持原始的URI，它不能执行这个重计算。

那么该怎么办呢？

你可以使用access.log里的数据来获取URI列表，它们可能位于cache里。然后，将它们用于squidclient或其他工具来产生PURGE请求，例如：
% awk '{print $7}' /usr/local/squid/var/logs/access.log \
        | grep www.example.com \
        | xargs -n 1 squidclient -m PURGE

7.6.3 删除所有对象

在极度情形下，你可能需要删除整个cache，或至少某个cache目录。首先，你必须确认squid没有在运行。

让squid忘记所有缓存对象的最容易的方法之一，是覆盖swap.state文件。注意你不能简单的删除swap.state文件，因为squid接着要扫描cache目录和打开所有的目标文件。你也不能简单的截断swap.state为0大小。代替的，你该放置一个单字节在里面，例如：
# echo '' >; /usr/local/squid/var/cache/swap.state

当squid读取swap.state文件时，它获取到了错误，因为在这里的记录太短了。下一行读取就到了文件结尾，squid完成重建过程，没有装载任何目标元数据。

注意该技术不会从磁盘里删除cache文件。你仅仅使squid认为它的cache是空的。当squid运行时，它增加新文件到cache里，并且可能覆盖旧文件。在某些情形下，这可能导致你的磁盘使用超出了自由空间。假如这样的事发生，你必须在再次重启squid前删除旧文件。

删除cache文件的方法之一是使用rm。然而，它通常花费很长的时间来删除所有被squid创建的文件。为了让squid快速启动，你可以重命名旧cache目录，创建一个新目录，启动squid，然后同时删除旧目录。例如：
# squid -k shutdown
# cd /usr/local/squid/var
# mv cache oldcache
# mkdir cache
# chown nobody:nobody cache
# squid -z
# squid -s
# rm -rf oldcache &

另一种技术是简单的在cache文件系统上运行newfs（或mkfs）。这点仅在你的cache_dir使用整个磁盘分区时才可以运行。

7.7 refresh_pattern

refresh_pattern指令间接的控制磁盘缓存。它帮助squid决定，是否某个给定请求是cache命中，或作为cache丢失对待。宽松的设置增加了你的cache命中率，但也增加了用户接收过时响应的机会。另一方面，保守的设置，降低了cache命中率和过时响应。

refresh_pattern规则仅仅应用到没有明确过时期限的响应。原始服务器能使用Expires头部，或者Cache-Control:max-age指令来指定过时期限。

你可以在配置文件里放置任意数量的refresh_pattern行。squid按顺序查找它们以匹配正则表达式。当squid找到一个匹配时，它使用相应的值来决定，某个缓存响应是存活还是过期。refresh_pattern语法如下：
refresh_pattern [-i] regexp min percent max [options]

例如：
refresh_pattern -i \.jpg$ 30 50% 4320 reload-into-ims
refresh_pattern -i \.png$ 30 50% 4320 reload-into-ims
refresh_pattern -i \.htm$ 0 20% 1440
refresh_pattern -i \.html$ 0 20% 1440
refresh_pattern -i . 5 25% 2880

regexp参数是大小写敏感的正则表达式。你可以使用-i选项来使它们大小写不敏感。squid按顺序来检查refresh_pattern行；当正则表达式之一匹配URI时，它停止搜索。

min参数是分钟数量。它是过时响应的最低时间限制。如果某个响应驻留在cache里的时间没有超过这个最低限制，那么它不会过期。类似的，max参数是存活响应的最高时间限制。如果某个响应驻留在cache里的时间高于这个最高限制，那么它必须被刷新。

在最低和最高时间限制之间的响应，会面对squid的最后修改系数 (LM-factor)算法。对这样的响应，squid计算响应的年龄和最后修改系数，然后将它作为百分比值进行比较。响应年龄简单的就是从原始服务器产生，或最后一次验证响应后，经历的时间数量。源年龄在Last-Modified和Date头部之间是不同的。LM-factor是响应年龄与源年龄的比率。

图7-2论证了LM-factor算法。squid缓存了某个目标3个小时（基于Date和Last-Modified头部）。LM-factor的值是50%，响应在接下来的1.5个小时里是存活的，在这之后，目标会过期并被当作过时处理。假如用户在存活期间请求cache目标，squid返回没有确认的cache命中。若在过时期间发生请求，squid转发确认请求到原始服务器。

图7-2 基于LM-factor计算过期时间

（略图）

理解squid检查不同值的顺序非常重要。如下是squid的refresh_pattern算法的简单描述：
+ 假如响应年龄超过refresh_pattern的max值，该响应过期；
+ 假如LM-factor少于refresh_pattern百分比值，该响应存活；
+ 假如响应年龄少于refresh_pattern的min值，该响应存活；
+ 其他情况下，响应过期。

refresh_pattern指令也有少数选项导致squid违背HTTP协议规范。它们如下：
override-expire
该选项导致squid在检查Expires头部之前，先检查min值。这样，一个非零的min时间让squid返回一个未确认的cache命中，即使该响应准备过期。

override-lastmod
改选项导致squid在检查LM-factor百分比之前先检查min值。

reload-into-ims
该选项让squid在确认请求里，以no-cache指令传送一个请求。换句话说，squid在转发请求之前，对该请求增加一个If-Modified-Since头部。注意这点仅仅在目标有Last-Modified时间戳时才能工作。外面进来的请求保留no-cache指令，以便它到达原始服务器。 

ignore-reload
该选项导致squid忽略请求里的任何no-cache指令。