nuster rule

syntax: nuster rule name [key KEY] [ttl TTL] [code CODE] [disk MODE] [if|unless condition]

default:none

context:backend

定义cache/nosql的生效条件，需要定义至少一个rule。

  1. nuster cache on
  3. # cache request `/asdf` for 30 seconds
  4. nuster rule asdf ttl 30 if { path /asdf }
  6. # cache if the request path begins with /img/
  7. nuster rule img if { path_beg /img/ }
  9. # cache if the response header `cache` is `yes`
  10. acl resHdrCache res.hdr(cache) yes
  11. nuster rule r1 if resHdrCache

可以定义多个rule，按定义顺序先后匹配。

  1. acl pathA path /a.html
  2. nuster cache on
  3. nuster rule all ttl 3600
  4. nuster rule path01 ttl 60 if pathA

rule path01永远不会被匹配。

name

定义rule的name。

在cache manager API中使用, 不必唯一但是建议不同的rule用不同的name，否则相同name的rule视作一样。

key KEY

定义cache/nosql的key, 由下列关键字加.组成

  • method: http method, GET/POST…
  • scheme: http or https
  • host: the host in the request
  • uri: first slash to end of the url
  • path: the URL path of the request
  • delimiter: '?' if query exists otherwise empty
  • query: the whole query string of the request
  • header_NAME: the value of header NAME
  • cookie_NAME: the value of cookie NAME
  • param_NAME: the value of query NAME
  • body: the body of the requestCACHE的默认key是 method.scheme.host.uri, NoSQL的默认key是 GET.scheme.host.uri.

Example

  1. GET http://www.example.com/q?name=X&type=Y
  3. http header:
  4. GET /q?name=X&type=Y HTTP/1.1
  5. Host: www.example.com
  6. ASDF: Z
  7. Cookie: logged_in=yes; user=nuster;

生成:

  • method: GET
  • scheme: http
  • host: www.example.com
  • uri: /q?name=X&type=Y
  • path: /q
  • delimiter: ?
  • query: name=X&type=Y
  • header_ASDF: Z
  • cookie_user: nuster
  • param_type: Y
  • body: (empty)默认key产生GEThttpwww.example.com/q?name=X&type=Y, 而key method.scheme.host.path.header_ASDF.cookie_user.param_type 则生成 GEThttpwww.example.com/qZnusterY.

实际内部会存储NULL分隔符，GET\0http\0www.example.com\0/q?name=X&type=Y\0

相同key的请求则会直接返回cache给客户端。

ttl TTL

设置缓存生存时间，过期后缓存会被删除。 可以使用 d, h, m and s。默认0秒.如果不希望失效则设为0

code CODE1,CODE2…

默认只缓存200的响应，如果需要缓存其他的则可以添加，all会缓存任何状态码。

  1. cache-rule only200
  2. cache-rule 200and404 code 200,404
  3. cache-rule all code all

disk MODE

定义缓存持久模式

  • off: 默认模式，仅保存在内存
  • only: 不保存在内存，仅保存在硬盘
  • sync: 保存到内存和硬盘后返回给客户端
  • async: 保存到内存后立即换回给客户的，内存数据会由master进程在一定时间后保存至硬盘

if|unless condition

定义ACL条件

ACL分别在请求阶段和响应阶段执行。

当下述条件满足时，会进行缓存：

  • 在请求阶段ACL为真
  • 请求阶段ACL为假，但是响应阶段ACL为真当使用否定的ACL或者某些样本获取方法时，需要特别注意

比如

  • 缓存以/img/开头的请求

nuster rule img if { path_beg /img/ }

请求阶段要么为真要么为假，因为在响应阶段无法获取path所以永远为假。

  • 缓存响应的http头部Content-Type 为 image/jpeg

nuster rule jpeg if { res.hdr(Content-Type) image/jpeg }

因为在请求阶段无法获取res.hdr所以永远为假，在响应阶段要么为真要么为假。

  • 以/img/开头，并且响应头 Content-Type 为image/jpeg时缓存如果定义为下面的规则，则不会成功：
  1. nuster rule img if { path_beg /img/ } { res.hdr(Content-Type) image/jpeg }

因为在响应阶段无法获取path所以永远为假，而在请求阶段无法获取res.hdr所以永远为假，那么这个ACL就永远无法匹配。

需要如下来定义：

  1. http-request set-var(txn.pathImg) path
  2. acl pathImg var(txn.pathImg) -m beg /img/
  3. acl resHdrCT res.hdr(Content-Type) image/jpeg
  4. nuster rule r3 if pathImg resHdrCT
  • 另一个例子，缓存所有不以 /api/ 开头的请求下面不正确：
  1. acl NoCache path_beg /api/
  2. nuster rule r3 if !NoCache

因为虽然在响应阶段path并不存在，所以NoCache永远为假，而 !NoCache 为真，所有的请求都会被缓存。

需要改成:

  1. http-request set-var(txn.path) path
  2. acl NoCache var(txn.path) -m beg /api/
  3. nuster rule r1 if !NoCache

会添加一些新的样本获取方法来简化这些操作。

详见HAProxy configuration的7. Using ACLs and fetching samples