• nuster rule
    • name
    • key KEY
    • ttl TTL
    • code CODE1,CODE2…
    • disk MODE
    • if|unless condition

    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