aiCache主要功能及配置

aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 1 ~ aiCachaiCachaiCachaiCacheeee主要功能及配置 功能一览 1. 模式化、智能化的动态微缓存和共享网络内容，包括GET和POST请求。 2. 全面支持正则表达式缓存设置模式匹配。 3. 基于RAM的缓存保障快速响应，而且不产生任何磁盘I/O。 4. 智能化的缓存内容清除，最高效使用RAM资源。 5. 通过缓存参数破坏，实现和后台更新同步，保证缓存内容及时更新。 ◦ URL触发缓存更新控制 ◦ 响应驱动缓存终止（header驱动缓存终止） ◦ 支持web界面生成的“expire”命令 ◦ CLI强制终止 6. 灵活的文件刷新控制，包括cookie驱动控制、URL触发缓存更新控制、响应驱动 缓存终止（header驱动缓存终止）等功能，让aiCache同步更新一个整体页面或 一个网页元素。 7. 可作为HTTPS终点，把解密的流量发送给原始服务器，从而对HTTPS内容加速。 8. 性能卓越、规模化扩展性强，每秒处理请求26万以上。 9. 可管理大量的并发连接。 10. 基于用户代理（user agent)的重定向。 11. 可自由配置的即时压缩。 12. 集群支持--运行一个中央管理、具有热备功能的aiCache服务器集群。 13. 集群同步--可选择性实现当一台aiCache服务器通过响应驱动缓存终止等文件刷 新控制时，其它集群中的所有aiCache服务器都同步刷新缓存内容。 14. 选择性日志压缩和抽取。 15. 根据时间或文件大小自动进行日志文件倒换。 16. 内置的全面健康监视器。 17. 对原始服务器实时监测，包括内容匹配。 18. 三种监测aiCache的方式：集群同步的CLI, Web和SNMP，而且提供极其丰富的 统计数字。 19. 功能丰富的命令行界面（CLI)：完整的统计，清单检查，文件过期和删除，日志 文件倒换等等。 20. 三种负载平衡式对网络服务器组群分配请求. 21. 抵御恶意请求和DOS/DDOS攻击的一系列安全保障功能：全面、多层防护，集 群同步。 22. 先进的预警功能，使网站管理人员能够在用户受到影响前处理任何故障或攻击。 23. 网站后备模式使网站即便在原始服务器瘫痪时也能在线。 24. 后备服务器救助功能，使网站在原始服务器瘫痪时也能正常运行。 25. 响应预载／预取 26. 通过aiCache插件架构支持客户端编程逻辑 27. 前端流量终止：卸载原始服务器和用户的连接（对话），TCP/IP请求。 28. “零开销”运行：不产生任何磁盘I/O,可相对无限扩展,具有无可比拟的规模化扩展 性。 29. 其它功能 aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 2 ~ 1. 加速100－1000倍 2. 节省服务器80％（4倍）以上 3. 每秒可处理请求26万个 核心数据 4. 并发连接数：60000多个（每个IP端口）。aiCache自身并无上限，并发连接的 多少只受限于原始服务器或网络。 5. https： ◦ 每秒15000个RSA-1024钥匙签署 ◦ 每秒处理25000个钥匙验证 ◦ 在DES或AES－256加密模式下，每秒传输1.5G个字节。 6. 零开销，对磁盘几乎不产生任何I/O(除了日志外）。 各功能使用 说明 关于失联党员情况说明岗位说明总经理岗位说明书会计岗位说明书行政主管岗位说明书 及配置方法 第一部分 缓存配置 基本概念： • 缓存：可共享 • 不缓存：不可共享 • 缓存模式：对可缓存内容定义的匹配标准。当一个请求响应匹配这些标准时，就 会缓存。 • TTL: 缓存内容有效期。第一个请求响应缓存的时间点即是一个TTL的起始时间 点。在该TTL内，所有的请求都是由AICACHE代理服务器来处理的。TTL结束 后，当有新的请求时，AICACHE会请求原始服务器以更新缓存内容，开始另一 个TTL，依此重复不止。(注意：TTL结束后，如果没有新的请求，AICACHE是不 去请求原始服务器检查更新内容的。） 缓存配置有几部分组成： • 缓存模式：决定匹配模式时缓存什么内容（URL, object--网页元素)。这是 aiCache智能化缓存的一种体现。 • 缓存更新：通过TTL设置定义缓存多长时间后aiCache对原始服务器请求更新内 容。 • 缓存清除：决定多长时间对aiCache内存中的缓存内容予以清除。 • 缓存破坏：即便某个url匹配某缓存模式，也不予缓存。 pattern级的配置会覆写website级的配置。 header在此文件中译为“标头”。 1.1.1.1. 缓存配置模式 1.11.11.11.1 配置行格式 parameter_name[space]param_value1[space]param_value2[space][#comment] aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 3 ~ 1.21.21.21.2 缓存配置模式 1.2.11.2.11.2.11.2.1 精确匹配模式 字符串必须精确匹配请求URL。该模式因匹配 能力低，应慎用。如： pattern / exact 10m （“/”为定义的字符串，url中必须有“/”才能缓存，缓存TTL为 10m) （有蓝色背景的两个参数都要根据实际需要更改。） 1.2.21.2.21.2.21.2.2 简单匹配模式 只要请求URL中含有模式定 义的字符串则可。如： pattern breakingnews.html simple 10m 只要请求URL中有breakingnews.html，就缓存，TTL为10m。 pattern /static_content/ simple 7d 只要请求URL中有/static_content/，就缓存，TTL为7天。 1.2.31.2.31.2.31.2.3 正则表达模式 用正则表达式定义缓存参数。该模式提供了更大的缓存匹配灵 活性和匹配能力。如： pattern ^aiCache regexp 1m (只要请求URL中有以aiCache开始的字符串，则缓存1分钟。） pattern tor$ regexp 1s （只要请求URL中有以tor结束的字符串，则缓存1秒钟。） pattern \.js regexp 7d （只要请求URL中有.js的字符串，则缓存7天。） 2.2.2.2. 特殊缓存配置 2.12.12.12.1 阻止响应缓存(Preventing caching of responses..... 68) 独有的私密信息（如用户个人资料）因不该共享，所以不能缓存。有两种方法能保证不去 缓存不能共享的内容： • 所有的缓存模式都不匹配。 • 在配置文件中对不能共享的内容定义缓存匹配模式，应把TTL设置为零，如： pattern viewmyprofile.jsp simple 0 aiCache还有其它控制缓存的方法，其它部分会加以说明。 2.22.22.22.2 非202020200000原始服务器响应对缓存请求的处理 (Handling of non-200 origin server responses to cacheable requests. .... 66) aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 4 ~ 多数HTTP响应有“200 OK”响应码。在处理缓存请求时，若aiCache得到非200响应， aiCache会再次对原始服务器请求，或者用过期的缓存内容作响应。如果再次请求失败， 而且过期的缓存内容已不存在，aiCache会根据不同的响应状态做出如下处理： • 302,301重导向：响应发送给请求用户，并根据TTL的设定予以缓存。 • 401，404， 407：响应发送给请求用户，但不缓存。 • 其它非200响应：aiCache用简短版覆写并发送给请求用户，除非有orig_err_resp 设置。这些响应均不缓存。 总之，aiCache尽量不缓存错误响应，并把给用户发送错误响应的工作最小化。 您也可 以通过"retry_non200"设置使aiCache在处理缓存请求时只接受200响应码，如： pattern /news.html exact 10 retry_non200 2.32.32.32.3 关于401,40401,40401,40401,407777响应(About 401, 407 responses ..... 67) 我们强烈建议不要缓存要求验证的内容。即，当请求含有验证HTTP标头时，aiCache即 对其TTL分配为零，即便该请求匹配某个缓存模式而且缓存中有有效的内容。同样道理， 当原始服务器发出401或407响应时，aiCache不加缓存直接发送给请求用户。 若您想让aiCache缓存要求验证的响应，您可在website级对所有的缓存请求添加一个提 前准备的授权header（pre-cooked authorization header)。当第一次请求或第一次更新 时，原始服务器会“误以为”用户已提前经过验证。这样，原始服务器就不会做出 401／407响应。如： httpheader Authorization Basic ZWRtbW12Zm5Ymmzy 请注意： • 该设置只对基本验证有效，不能用于摘要验证(digest authentication)。 • 您可以用HTTP标头捕捉工具，如HTTPheader, Firebug, Fiddler等，来捕捉合适 的值用于httpheader授权。 2.42.42.42.4 允许cookicookicookicookieeee穿透缓存响应（Allowing Cookie pass-through for cacheable responses. ..... 77 ） 众所周知，不可分享的0ttl响应总是由原始服务器直接提供给用户。当原始服务器发出含 有一个或数个Set-Cookie HTTP header时，aiCache缓存的只是经过过滤的内容，象用户 个人信息这些内容是不缓存的。但是，在某些情况下，您可以通过pattern级添加参数 pass_cookie设置让某些cookie从原始服务器穿过缓存响应： pass_cookie lastvisit (含有lastvisit这个cookie的响应允许进入缓存响应。) 2.52.52.52.5 缓存响应的签名(Signatures of cached responses... 77) aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 5 ~ aiCache默认使用主机名、请求URL（可能去处某些参数或摈弃全部查询字符串），和一 个"p0","p1","g0",或"g1"的后缀。每个缓存响应都有一个签名。每个签名都有至少以下3部 分组成（每部分间用空格分开）： • 主机名 • URL: 请求路径 ＋ 可选可变的查询字符串 • p0或p1 / g0或g1 除了以上三部分外，也可添加更多的组件，如Cookie（sig_cookie）、用户代理字符串 (sig_ua)、重写的用户代理字符串(user agent string)、客户端可接受的语言标头(accept- language request header)等。 当你运行CLI的"inventory"命令时，可以在尖括号中看到缓存响应的签名(>signature<)。 为了影响缓存响应（如终止缓存），你需要指定一个精确的缓存响应签名，或一个匹配模 式。你可以通过复制粘贴CLI（命令行界面）inventory命令的字符串到尖括号中来获取精 确签名。如：>aaa.bbb.com/home.html p1< 2.62.62.62.6 在缓存响应签名中填加cookicookicookicookieeee值(Adding a Cookie value to signature of cacheable responses...78) 如2.5所述，每个缓存响应都有自己的签名(指针)。但有些网站根据请求中的某个cookie值 对同一个URL请求提供不同的响应内容。如：你对index.html设置一个"language"的 cookie，并给它赋值"en"和"cn"。aiCache对含有不同cookie值的请求提供不同内容的响 应---英文版或中文版。 配置很简单，只需在website级或pattern部分配置：sig_cookie language 第一次响应或更新过期的缓存响应时，aiCache把cookie及其值发送给原始服务器（这和 正常处理cookie不同）。每个website和pattern仅允许分别配置一个sig_cookie，可以结 合sig_ua，sig_language和sig_cookie进行设置。选定的Cookie值、Accept-Language header和用户代理header都是响应签名的一部分。 注意：要谨防因失误而缓存用户的私有数据。 2.72.72.72.7 在缓存响应签名中添加用户代理标头 (Adding User-Agent request header to signature of cacheable responses. .... 79) 如2.5和2.6所述，你可以把手机的用户代理信息（字符串）作为用户代理的HTTP header 值添加到缓存响应的签名中。因为用户代理http头包含了浏览器的品牌和型号，所以 aiCache能够针对不同品牌型号的手机发送不同的缓存内容，即，适合该手机浏览器、分 辨率和屏幕大小的内容格式。若使用该功能，请在配置文件的website级设置sig_ua。你 还可结合sig_ua和sig_cookie设置使用，即，选定的Cookie值和用户代理字符串共同作为 缓存响应签名的一部分。 aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 6 ~ 说明：这个配置会增加缓存内容，所以应慎重使用。为了减少缓存内容，同时也减少内容 格式制作和更新维护的工作量，可根据浏览器、分辨率和屏幕大小通过用户代理http header值将手机分群。 2.82.82.82.8 在缓存响应签名中添加重写／减少的用户代理请求标头 (Adding reduced/rewritten User-Agent request header to signature of cacheable responses...79) 市场上有上千种手机，加上有多家移动通讯提供商，每种手机都有自己的用户代理字 符 串。因此，给不同的手机提供不同的内容格式是项极具挑战性的工作。如2.5, 2.6, 2.7 所 述，该功能让您把用户代理字符串重写／减少成组（一组对应一个缓存响应签名），并 使 用重写或减少的值作为缓存响应的一部分，从而使不同的手机用户访问同一个URL，但 获取不同格式的响应内容。您可依据手机的浏览器，屏幕大小，功能，是否支持CSS和 Javascript等对手机分群，并以此制定用户代理字符串的重写规则。功能配置举例如下： 在website级配置ua_sig_rewr。该配置有两部分：匹配模式和重写字符串。如： ua_sig_rewr .*BlackBerry8.* berry8 (所有匹配.*BlackBerry8.*的用户代理字 符串重写到berry8，即由多个减少到一个) ua_sig_rewr配置也可有第三个参数：0ttl_ua。如： ua_sig_rewr .+ non_js 0ttl_ua (当手机不支持Javascript时，不缓存该用户代理请求响应。) 有些手机支持Javascript（如BackBerry和iPhone),有些手机不支持Javascript。支持JS的 手机客户端可生成JS，而不支持JS的手机必须由服务器端生成后不经缓存发送给手机用 户。象这种情况，您可以用这种配置方法解决： 在website级配置： ua_sig_rewr .*BlackBerry8.* berry8 ua_sig_rewr .*iPhone.* iphone ua_sig_rewr .............. ......... ua_sig_rewr .+ non_js 0ttl_ua 同时在pattern级配置： pattern /news.html 60 0ttl_ua 用户代理匹配模式说明： • 必须使用"\s"代替空格 • 替换字符串可使用“反向指代”(back-reference)来匹配匹配字字符串中的群组，即 用"\1", "\2"等来指代第1，第2群组。 • 如：.*Blackberry\s7.* 另外，该功能还有以下好处： aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 7 ~ • 使手机格式从100多种减少到十几种，从而大大降低了手机网站的建设成本和维 护成本。 • 减少缓存版本，提高缓存命中率。 • 减少对原始服务器的请求。 • 简化应对市场上众多型号手机的逻辑。 建议：配置好后用pattest工具测试。 2.92.92.92.9 在缓存响应签名中添加““““接受语言””””请求标头 (Adding Accept-Language request header to signature of cacheable responses. . 82) 多语言版本的网站用二级域名（如en.xyz.com, cn.xyz.com）或URL命名方法（如 xyz.com/en/URL, xyz.com/cn/URL），给不同语言的用户提供不同语言版本的内容。这 种情况下，无需使用该功能。 有些网站用浏览器的“接受语言”标头来指定用户喜欢的语言。如，当接受语言标头设 为 "us-en,en"时，网站内容是 英语 关于好奇心的名言警句英语高中英语词汇下载高中英语词汇 下载英语衡水体下载小学英语关于形容词和副词的题 ；当接受语言标头设为"ca-fre,fre"时，网站内容是法 语。 换句话说，不同语言的用户访问的URL是一样的，但获取的网页内容是不同语言版 本 的。对这种情况，您可通过在缓存响应签名中添加“接受语言”请求标头让aiCache缓存 响 应不同语言版本的内容。 使用该功能，只需在website级或pattern级设置"sig_language"。该设置是flag，所以不需 要参数。但通过CLI的inventory命令，您可以看到相应的不同缓存签名。 说明： • 基于用户浏览器及其语言环境设置的不同，接受语言标头值可能会有些变异，导 致同一接受语言标头有不同的缓存版本（如中文中分简体中文和繁体中文），从 而降低缓存命中率。所以，应慎用该功能。 2.102.102.102.10 会话驱动内容的缓存(Session-driven content caching. [ cluster/peer enabled] .. 83) 该功能适用于需登录才能访问网页的网站（除首页外）。只有登录用户才能共享缓存 内 容。这一功能给需登录才能正常访问的社交网站、才能浏览新闻的新闻网站、才能察看 信 息的资讯网站等提供了一个完美的解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 。 要实现该功能，一要知道对用户成功登录设定的cookie，二是要知道哪个URL设定的这个 cookie。假设用户登录的cookie是sessionid，用户登录的URL是login.php，用户登录后 才能共享的缓存内容是/paidcontent/，那么该功能的配置如下： a. 在website级配置session_cookie: session_cookie sessionid b. 在pattern级的匹配模式中设置sets_session_cookie的pattern级flag: pattern /login.php exact 0 request_type both aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 8 ~ sets_session_cookie c. 在pattern级的缓存匹配模式下设置session_cookie_required这一pattern级flag: pattern /paidcontent/ simple 1m session_cookie_required 通过上面这些配置，当aiCache发现匹配响应中有session cookie时，aiCache就会记住这 个session cookie的值，并告知其“同事”（在aiCache集群中）。当，也只有当aiCache看 到这个有效session cookie时，aiCache才会给/paidcontent/的URL请求提供缓存内容。对 没有登录的用户请求，aiCache将其交给原始服务器处理。 您也可在global级设置session_duration来定义会话期（以秒为单位）。aiCache的默认是 3600秒。 若您的原始服务器没有会话状态复制机制(session state replication mechanism)，您可在 website级设置session_cookie_persist。该设置是个旗（flag)，不要求参数。做了该配置 后，aiCache总是把请求发送给设定某session cookie的原始服务器。 该功能是通过session cookie的设置让不同的登录用户共享相同的缓存响应内容。在极端 的情况下，您也可选择通过sig_cookie设置，把它设为和session_cookie同值，根据每个 用户去缓存内容。 aiCache会通过web, CLI和SNMP 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 以上相关日志。 2.112.112.112.11 POSPOSPOSPOSTTTT请求的响应缓存(Caching of responses to POST requests. ... 93) 当缓存GET请求时，响应签名是从原始请求的路径和查询字符串组成的。但POST请求的 标头中可能没有查询字符串。有些POST请求的查询字符串是嵌入到请求正文中的。这些 POST正文是URL编码的（即：有指定Content-Type: application/x-www-form- urlencoded标头)。另外有些POST请求的查询字符串可能在URL中有一部分，在正 文 中、XML格式的正文中、纯文本正文中、或序列化Java的POJO正文中有一部分。 只要POST文本含有数个URL编码的变量，生成需要的签名就不会有问题。但有些POST 请求缓存响应的签名，如SOAP类的请求，其响应签名会变得很长，所以生成这些签名会 花费更多的时间。这种情况下，需要aiCache通过在global级的max_post_sig_size设置 （默认256字节），限制可作为签名的文本长度（但要确保每个签名都是唯一的）。 一个可缓存的POST请求，必需符合如下标准： • 请求的URL必须匹配这么一个模式：有设为post或both的request_type设置。 • 匹配模式的TTL必须非零。 • 用作签名的POST正文不能大于max_post_sig_size上限。 • 若有缓存破坏Cookie，不能存在于请求中。 • 不出现授权标头（Authorization header） aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 9 ~ 和GET请求的缓存相似，URL编码的POST请求的缓存响应签名也可通过ignore_param的 配置破坏缓存参数以减少缓存内容（详见本部分5.3)。非URL编码的POST请求，因其没 有可识别的参数，不能使用缓存参数破坏。 当响应签名中含有CR(carriage return)和/或LF(line feed)字符时，在CLI中为了使用dump 命令而指定这些签名可能会有困难。为了诊断这些响应，您可使用CLI的inventory命令。 当一个单一的响应匹配提供的主机名和模式时，该响应就会被写出到一个文件，像dump 命令一样。这样，您可以很方便地借助一个部分匹配去找到并写出缓存响应。 您可选择不用POST请求的正文作响应签名。您可让程序员改一下代码，给POST URL添 加有意义的、可读的参数。如此，您就可以用这些添加的参数作响应签名，而不必再用 POST正文（可通过sig_ignore_body设置实现禁用post正文作签名）。 2.12 即时压缩功能(On-the-fly Response Compression. .... 86-87) 现在的大多数网络服务器都可以压缩网络内容。如果您的网络服务器负荷太大，想让 aiCache做即时内容压缩，可设置： min_gzip_size 2000 (响应内容长度减去header大小后等于或大于2000字节时， aiCache对text/html, text/css 和application/x-javascript格式的内容进行即时压缩。) 使用aiCache即时压缩功能需注意以下问题： • 启用即时压缩功能占用更多的aiCache服务器内存。所以，除非网络服务器负荷 太大，建议由网络服务器压缩内容。 • 设定压缩的内容长度最小为2000字节，否则压缩没有意义。 • 所有类型的浏览器都支持html, CSS和Javascript的压缩。这些是aiCache默认压 缩的文件类型。 • 若想压缩Json和XML文件，可在配置文件的global级或website级设置： compress_json和compress_xml。（请注意：有些浏览器不支持这类压缩文 件。） • 只有请求header表明支持gzip压缩时，aiCache才会压缩响应。 • 当aiCache识别JS, CSS, JSON和XML类的请求响应来自来自IE6和IE5时， aiCache不执行即时响应压缩，因为IE5和IE6对这类压缩会出现问题。可在global 级设置 no_gzip_ie56，以减少aiCache的工作量（识别）。 • aiCache即时响应压缩在一个工作线中进行。因此，一个大的用户响应压缩不会 影响其他用户的响应压缩。 2.132.132.132.13 对压缩和非压缩响应的处理和存储 (Handling and storing of compressed (gzipped) and plain responses. . 85) 对同一个URL的压缩和非压缩响应，aiCache都进行缓存。这两个版本的缓存响应是一个 URL, 且TTL相同（但因为缓存发生的时间不同，所以更新的时间点不同）。另外， HTTP/1.1和HTTP/1.0也是两个缓存版本。 aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 10 ~ 2.142.142.142.14 对HTTP/1.HTTP/1.HTTP/1.HTTP/1.1111和HTTP/1.HTTP/1.HTTP/1.HTTP/1.0000的缓存响应存储不同的版本 (Storing different versions of cached responses for HTTP/1.1 and HTTP/1.0 clients. ..... 103) 为应对HTTP/1.1和HTTP/1.0用户的不同需求，aiCache对一个URL可能缓存4个版本： • 对HTTP/1.1用户的压缩和（可能）组块化的响应，该响应的签名中含有"g1"； • 对HTTP/1.1用户的非压缩和（可能）组块化的响应，该响应的签名中含有"p1"; • 对HTTP/1.0用户的非压缩响应，签名中含有"p0"。aiCache不主动去寻找对 HTTP/1.0请求的压缩或组块化响应。 • 对HTTP/1.0用户的压缩响应，签名中含有"g0"。在global级配置 enable_http10_gzip时，才会有这种情况。 2.152.152.152.15 客户端个性化处理的缓存(Client-Side Personalization Processing ....218-220) 有些网站有这样的情况，当用户登录后，网页会显示出“欢迎！张三","您好，李四"等等这 样的问候语，这部分内容是变化的，不可共享的，网站又不能因这1%（不可缓存的 内 容）而放弃99%（可缓存的内容)，将网页设置不可缓存的。 针对这一难题，aiCache提供了一种很好的解决方法，即，把问候的处理逻辑交给客户 端。几行Javascript就可达到这一目的。例如： 手册 华为质量管理手册 下载焊接手册下载团建手册下载团建手册下载ld手册下载 中有范例代码供您借用。请参手册中最后的附件C。 2.162.162.162.16 缓存最佳实践(Best practices to maximize benefits of caching. .... 68) • 根据内容更新的周期相应设置TTL的长短。不常变化的内容，如CSS, JS文件，图 像和其它辅助内容等，允许缓存更长的时间。aiCache发送缓存内容的机制允许 客户浏览器端适当缓存，从而更提高了缓存的效率。 • 即便缓存数秒，也会产生巨大的变化。假设某个URL每秒有100个请求，把TTL设 为1秒。那么在这1秒的时间内，原始服务器只处理1个请求，减轻原始服务负荷 99倍！若把TTL设为5秒，就会减轻服务器负荷499倍！一个目前需要几十台服务 器支撑的网站，使用aiCache后，可能只要两、三台服务器就够了。 • 可考虑使用不同版本的辅助内容来更好地控制网站的更新。如，当你需更新一个 script.js的文件时，把新文件命名为scriptV2.js。发布后，所有的含有该文件的网 页都会同步更新，避免了ISP http代理和本地浏览器缓存造成的更新延迟。 aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 11 ~ 重要的是，使用aiCache缓存不需对原来的web服务器、应用服务器和数据库服务器做任 何修改, 也不需您的开发团队编写任何代码来处理更新控制。aiCache让您控制内容更新 易如弹指。 3.3.3.3. 缓存更新或终止 缓存更新是为了确保用户得到新鲜的响应内容，可通过TTL 设置和强制更新来实 现。TTL设置的长短要根据URL更新的频繁度（周期）而定。 在某些情况下（如电子商务网站产品库存更新、媒体即时新闻、论坛发帖更新等），需要 强制结束TTL，以保证AICACHE的缓存内容和和原始服务器的更新同步。 3.1 响应驱动缓存终止：同步更新(Response-driven Cache Invalidation. [ cluster/peer enabled] ..... 82) 该功能通过在响应中给aiCache发送一个X-expireURL的header来终止某个缓存。如，在 一个论坛，当用户发新帖时程序会给对aiCache发送一个请求，通过这两种配置来更新论 坛页面或某跟帖页面的缓存： X-expireURL: /acme-bb/forumdisplay.php?f=123 会终止该论坛网页的缓存。 X-expireURL: /acme-bb/showthread.php?t=123456 会终止某跟帖网页的缓存。 Java和PHP等都能很容易地在响应中插入类似的header。如果您用的是Java（对同一个 名称不可以有多个header数值），而且想同时终止几个URL的缓存，您可以用这个命令 配置： X-expir1URL, X-expir2URL （即，把X-expireURL中U前的e换成数字。） 请注意，X-expireURL后是缓存终止参数。如果想终止某一特定响应，可在该参数后加上 \s。 关闭该功能可通过在website级或pattern级设置"ignore_resp_expire"来实现。 3.2 cookie驱动缓存控制(Cookie-driven Caching Control......75) 很多情况下，网页的内容会根据请求中有无cookie而变化。如，一个登陆用户的响应页面 会和匿名用户的不同，象登陆用户的页面上会有“你好，xx用户”。这种情况下，可用 cookie驱动缓存控制来缓存匿名用户的页面，而把登录用户的请求响应交原始服务器 处 理： 0ttl_cookie uderid (当请求中有useid这个cookie时，请求由原始服务器处理。) aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 12 ~ 相反的pattern级设置是： cache_cookie xyz （当请求中有xyz这个cookie时，进行缓存。） 3.3 URL触发缓存更新控制(URL-triggered Cache Freshness Control. ..... 76) 有时，在请求中出现某cookie前就需要终止缓存，如一个电子商务网站的用户在登录之前 就开始使用购物车。这种情况下，可用URL触发缓存更新控制来制止缓存： 0ttl_url basketAdd.jsp (当用户访问含有basketAdd.jsp这个URL时，缓存就终止。) 0ttl_url login.jsp (当用户访问含有login.jsp这个URL时，缓存就终止。) 3.4 通过响应header或响应大小检查强制重新更新(Forcing retry (refresh) by response header or response size check. .. 96) 您可配置aiCache通过回送一个特别的响应标头"X-NoCache"对缓存请求强制重试（标 头值可任意指定）。另一个方法是，通过在pattern级配置retry_min_resp_size和 retry_max_resp_size指令，指定可接受的最小和最大响应大小，来向aiCache表明某 响应无效而强制重试更新。 您可在website或pattern级指定no_retry来关闭重试。 3.5 禁止下游响应缓存(Disallowing downstream caching of responses. .... 97) 下游响应缓存是指用户浏览器端缓存。在某些情况下，如更新频繁的论坛页面，为了让用 户获取最新的响应内容，需要禁止下游响应缓存。要达到这个目的，只需把TTL设置为负 值，如： pattern xyz.htm simple -600 (xyz.htm缓存10分钟，但不允许下游缓存。aiCache会发送 Expires header来禁止下游缓 存) 注意：对JS和CSS文件永远不做如此设置。 另外，在website级设置 "send_cc_no_cache"，aiCache会对这些响应添加"Cache- Control: no-cache"的header，以禁止下游缓存。 3.6 更改文件名以达到及时更新(SCRIPT.JS)(... 68) 举例来说，一个网页有一个Javascript文件scrip.js，当你在后台更新该文件时，你可把 新文件命名为scriptV2.js。这样，一旦后台发布，script.js这个缓存就会在有新请求时 aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 13 ~ 更新为scriptV2.js。（因为响应在缓存中找不到script2.js这个文件而需要到原始服务器 请求。） 4.4.4.4. 缓存参数破坏 缓存参数破坏是指在某种情况下，即便请求URL匹配了某缓存模式， aiCache也不对该 URL进行缓存。如： 4.1 cookie驱动缓存控制(见3.2) 4.2 URL触发缓存更新控制（见3.3) 4.3 缓存路径管理(见5.2) 4.4 查询参数破坏（见5.3) 4.5 忽略大写设置（见5.4) 5.5.5.5. 缓存大小管理 如果网站繁忙且缓存量巨大，可通过aiCache的四种缓存总量管理方法 来控制缓存总量， 提高aiCache服务器的内存使用效率。 5.1 缓存清除控制(Cache size management via cache cleaner process..... 87) 缓存清除功能用来清除aiCache内存中的缓存内容，以提高内存利用率。和合理设置TTL 一起，该功能对热点分散造成的缓存量巨大这一难题提供了很好的解决方案。如果您的网 站有许多一定时间访问过后很少有用户再次访问的内容，缓存清除功能也是一种解决无意 义缓存堆积的有效方法。 缓存清除控制有软清除和硬清除两种： 5.1.1 软缓存清除： aiCache则清除缓存内容，但保留请求和响应记录。命令配置： cache_cleaner_interval 60 (每60秒做 一次软清除。参数为秒数。) 5.1.2 硬缓存清除： aiCache清除缓存内容和请求／响应数据记录。命令配置： hard_cache_cleaner_interval 120 (每120秒硬清除缓存内容 及其请求响应记录。参数为秒数。) aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 14 ~ 说明： • 一般情况下，缓存清除设置不管缓存内容的TTL是否过期，对缓存内容都予以清 除。 • 如果不想让缓存清除控制清除掉TTL期内的缓存内容，可在website级设置： cc_obey_ttl。这个设置让缓存清除只清除TTL过期的缓存内容。 • 也可设置为不管缓存是否有请求，都在某时间段清除。 • 要关闭缓存清除功能，在website级设置： cc_disable 5.2 缓存路径管理(Cache size management via Cache-by-Path Feature. .... 88 ) aiCache根据缓存模式配置判断是否缓存某内容是基于URL的，而判断是否提供或提供哪 个缓存内容也是基于URL的。aiCache的这一工作原理在以下两种情况下会出现“无效缓 存备份”（即：相同的网页因请求的URL不同而缓存多份）： 1. 某些网站有许多的第三方网站链接，当某第三方网站的链接指向网站的某一网页 （如www.xyz.com/example.html)时，为了识别并统计这些请求来源而用不同的 url（如： www.xyz.com/example.html?partnerid=partner1)。尽管这些URL指向 的网页内容都是同一个，但正常配置下，aiCache这时会毫无意义地缓存所有的 URL而造成“缓存污染”。 2. 某些网站对不同的登陆用户的请求URL添加随机字符串，以达到某种目的，如： 识别哪个用户何时访问了哪个网页。和上面的情况相似，尽管请求的URL不同， 但网页内容都是一样的。这样也造成缓存污染，或者因这些随机字符串而导致无 法匹配缓存。 aiCache通过缓存路径管理，对上述情况的不同URL只缓存一份网页内容（因为响应的内 容都一样），即，上例中的www.xyz.com/example.html，而不缓存哪些含有来源识别的 参数或随机字符串的URL，同时对其它URL请求提供缓存的内容--www.xyz.com/ example.html。 功能配置： pattern html simple 10m ignore_query 5.3 查询参数破坏(Cache size management via query parameter busting. .. 91) 查询参数破坏指aiCache缓存或提供响应时忽略URL中的部分参数。象5.2中的情况，也 可以通过查询参数破坏来应对。配置如下： ignoreparam partnerid 如此，当出现www.xyz.com/showstory.asp?stoyid=1234&partnerid=partner1请求时， aiCache提供缓存的www.xyz.com/showstory.asp?storyid=1234来响应。 也可设置部分参数破坏来应对这中情况，如： aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 15 ~ param_partial_match bust (破坏含bust的参数，如bustXXX, bust YYY) 5.4 忽略大写设置(Cache size management via ignore case feature.... 92) 通常情况下，aiCache设置是区分大小写的。如想让aiCache忽略不区分大小写，可在 website级或pattern级设置“ignore_case"。该功能在以下两种情况下非常有用： • 搜索结果缓存（用户可能输入大写或者小写，尽管搜索结果都一样） • 股票信息查询（用户可能输入大写或者小写，尽管搜索结果都一样） 6.6.6.6. 模式测试工具(Pattern testing tool... 32) 为便于创建和测试正则表达式匹配和重写模式，aiCache带有一个命令行工具： pattest。 该工具的安装脚本在aiCache二进位目录中。您也可将其移至/usr/local/ bin。 该工具让您对正则表达匹配和更复杂的正则表达重写进行测试。您只需在pattest命令下 指定测试的匹配模式、要测试的字符串和可选的重写字符串。如： # ./pattest -p '^abc' -s abcdef [Success]: Matched. Pattern: >^abc< String: >abcdef< # ./pattest -p '(abc).*' -s abced -r 'ZZZ' [Success]: Rewrote original string: >abced< To new string: >ZZZ< Using pattern: >(abc).*< And replacement string: >ZZZ< 7.7.7.7. URURURURLLLL匹配动作 aiCache的智能化从URL匹配动作中可见一斑。如果一个URL匹配了aiCache配置的某个 模式，aiCache可对该URL做出以下动作： • 对其进行TTL设置（如TTL是零，则不缓存）。 • 阻止该URL。 • 对该URL重定向。 • 对该URL重写。 • 对该URL重写并重定向。 • 对该URL不进行日志记录。 • 对该URL中的部分或全部参数摒弃（“URL缓存签名参数破坏”功能）。 • 该URL可有cookie，并将其参数添加到该URL的缓存签名中。 • 该URL可含有用户代理（user-agent)请求，可并其数值添加到该URL的缓存签 名中。 • 该URL可含有用户代理请求，并将该URL的用户代理重写并添加到该URL的缓存 签名中。 • 该URL可含有“接受语言”（Accep-Language)参数，并将其数值添加到缓存签名 中。 aiCache (China) Website: aicache.cn Tel: 800.883.8918 / 400.616.1918 ~ 16 ~ • 如果请求中有某个cookie,可将该URL的TTL设为零（即：不再缓存）。 • 可允许缓存一个或多个从原始服务器响应中生成的cookie。 • 可执行客户端提供的插件代码。 • 其它动作。 第二部分 重写和重定向 1.1.1.1. URURURURLLLL重写和重写重定向(URL rewriting and rewrite-redirection..... 69) 重写：URL请求指向另一个路径（文件夹） 重定向：更换URL为另一个URL 该功能通过在匹配模式部分指定rewrite参数来配置。重写命令包括两个参数：from pattern和replacement string。 在如下类似情况下，需要使用重写和重定向功能： • 把网站的图片从/images/移到/media/images时，需要把对/images/下的文件的请 求指向/media/images，以不影响网页正常访问。配置如下： pattern /images simple 30m rewrite /media/images (这种重写后的URL继承匹配模式的TTL设置。) • 把所有的辅助内容从www.xyz.com移到media.xyz.com。此时，当用户请求/css, /js, /images时，需把请求指向media.xyz.com，无论是保持原有URL或是更换原 URL。如，对www.xyz.com/image/1x1.gif的请求需重指向media.xyz.com/media/ images/ix1.gif。 要实现重写并重定向，替换字符串（replacement string)必须以http://开始。配置如下： pattern /image simple 30m rewrite /image http://media.acmenews.com/media/images (在重写并重定向时，TTL设置失去了意义，但仍必须在匹配模式中存在以符合模式定 义的语法。) • 一个呈现论坛网页的URL编码从displayforum.php?forum=123改为 showtopic.jsp?fid=123，为了使用户原有的书签仍能有效访问，也需使用该功 能。配置如下： pattern displayforum.php simple rewrite displayforum.php\?forum=(\d+) showtopic.jsp?fid=\1 (该配置在from_pattern中使用了 模式组群，并在替换模式中使用了逆向引用。在替换模 式中，\0代表整个匹配的字符 串，\1代表定义的第一个组群。) 说明： • 为了对重写模式微调、测试、排障，可在global级或website级配置log_rewrite启 用重写日志。也可用pattest进行。 • aiCache的重写和重定向功能不同于一