一个根据是否缓存来存信息到redis的问题

yanvcl · 2014-07-18T14:37:04+00:00

Hello! 2014-07-17 22:32 GMT-07:00 coderesty: > 问一下, 我想把post的数据打印到a...

一个根据是否缓存来存信息到redis的问题

yanvcl

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，

使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。

谢谢！

smallfish.xy

用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <ya...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

yanvcl

ngx.shared.DICT这个有三个问题：

1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。
3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：

用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

smallfish.xy

2014-07-18 15:19 GMT+08:00 Jack Yan <ya...@gmail.com>:

ngx.shared.DICT这个有三个问题：
1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

不管哪种方案，初始化值都需要自己手动，这个属于业务范围，只有自己知道。

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。

使用 ngx.shared 的话，不需要这个变量了

3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

用 uri 作为 ngx.shared 的 key，也可以自己配置 expires

其实这里的用法就像普通使用 cache（memcache）一样，先判断是否有，有就干啥，没有有就执行啥啥。

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：
用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

--

yanvcl

这个确实是可行的，就是用ngx_shared当作nosql用，来存这些url，持久化的话可以再放一份到redis，

不知道我理解的对不对，这样用是不是合理。

但是我有个问题就是ngx_shared占用nginx内存，

如果资源比较多的话，占用的内存还比较多。

在 2014年7月18日星期五UTC+8下午3时25分26秒，smallfish写道：

2014-07-18 15:19 GMT+08:00 Jack Yan <yan...@gmail.com>:

ngx.shared.DICT这个有三个问题：
1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

不管哪种方案，初始化值都需要自己手动，这个属于业务范围，只有自己知道。

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。

使用 ngx.shared 的话，不需要这个变量了

3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

用 uri 作为 ngx.shared 的 key，也可以自己配置 expires

其实这里的用法就像普通使用 cache（memcache）一样，先判断是否有，有就干啥，没有有就执行啥啥。

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：
用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

--

lancelijade

你确定放在 access_by_lua 会对性能有影响？如果只是简单键值存取，redis性能正常，ngx-lua启用长连接的话，这个速度应该非常快，在整个http请求周期内占的比重相当小。

Lance

2014-07-18 16:37 GMT+08:00 Jack Yan <ya...@gmail.com>:

这个确实是可行的，就是用ngx_shared当作nosql用，来存这些url，持久化的话可以再放一份到redis，
不知道我理解的对不对，这样用是不是合理。
但是我有个问题就是ngx_shared占用nginx内存，
如果资源比较多的话，占用的内存还比较多。

在 2014年7月18日星期五UTC+8下午3时25分26秒，smallfish写道：

2014-07-18 15:19 GMT+08:00 Jack Yan <yan...@gmail.com>:

ngx.shared.DICT这个有三个问题：
1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

不管哪种方案，初始化值都需要自己手动，这个属于业务范围，只有自己知道。

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。

使用 ngx.shared 的话，不需要这个变量了

3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

用 uri 作为 ngx.shared 的 key，也可以自己配置 expires

其实这里的用法就像普通使用 cache（memcache）一样，先判断是否有，有就干啥，没有有就执行啥啥。

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：
用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

--

--

yanvcl

我之所以要判断一下，是因为我觉得，既然已经缓存过了的文件，就不需要再去访问redis，这样就能减少访问redis的次数

如果每次进来的url，都去请求一下redis，不说性能问题，起码就比较占资源，多了无用的tcp请求，

我想如果能在nginx内部就判断出来，就不需要再去操作redis了，反正就是尽量优化，实在不行的话那也没办法咯。

在 2014年7月18日星期五UTC+8下午4时43分33秒，Lance Li写道：

你确定放在 access_by_lua 会对性能有影响？如果只是简单键值存取，redis性能正常，ngx-lua启用长连接的话，这个速度应该非常快，在整个http请求周期内占的比重相当小。

Lance

2014-07-18 16:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

这个确实是可行的，就是用ngx_shared当作nosql用，来存这些url，持久化的话可以再放一份到redis，
不知道我理解的对不对，这样用是不是合理。
但是我有个问题就是ngx_shared占用nginx内存，
如果资源比较多的话，占用的内存还比较多。

在 2014年7月18日星期五UTC+8下午3时25分26秒，smallfish写道：

2014-07-18 15:19 GMT+08:00 Jack Yan <yan...@gmail.com>:

ngx.shared.DICT这个有三个问题：
1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

不管哪种方案，初始化值都需要自己手动，这个属于业务范围，只有自己知道。

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。

使用 ngx.shared 的话，不需要这个变量了

3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

用 uri 作为 ngx.shared 的 key，也可以自己配置 expires

其实这里的用法就像普通使用 cache（memcache）一样，先判断是否有，有就干啥，没有有就执行啥啥。

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：
用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

--

--

yanvcl

哦，对了，我所说的对性能的影响，不是别的意思，就是指那多余的redis请求。

在 2014年7月18日星期五UTC+8下午4时43分33秒，Lance Li写道：

你确定放在 access_by_lua 会对性能有影响？如果只是简单键值存取，redis性能正常，ngx-lua启用长连接的话，这个速度应该非常快，在整个http请求周期内占的比重相当小。

Lance

2014-07-18 16:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

这个确实是可行的，就是用ngx_shared当作nosql用，来存这些url，持久化的话可以再放一份到redis，
不知道我理解的对不对，这样用是不是合理。
但是我有个问题就是ngx_shared占用nginx内存，
如果资源比较多的话，占用的内存还比较多。

在 2014年7月18日星期五UTC+8下午3时25分26秒，smallfish写道：

2014-07-18 15:19 GMT+08:00 Jack Yan <yan...@gmail.com>:

ngx.shared.DICT这个有三个问题：
1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

不管哪种方案，初始化值都需要自己手动，这个属于业务范围，只有自己知道。

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。

使用 ngx.shared 的话，不需要这个变量了

3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

用 uri 作为 ngx.shared 的 key，也可以自己配置 expires

其实这里的用法就像普通使用 cache（memcache）一样，先判断是否有，有就干啥，没有有就执行啥啥。

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：
用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

--

--

lancelijade

那你加这个redis记录的目的何在呢？如果已经有缓存，nginx 自己处理，如果没缓存，nginx 自己处理，你记下来，最后只是为了统计请求了多少次后端？

Lance

2014-07-18 16:58 GMT+08:00 Jack Yan <ya...@gmail.com>:

哦，对了，我所说的对性能的影响，不是别的意思，就是指那多余的redis请求。

在 2014年7月18日星期五UTC+8下午4时43分33秒，Lance Li写道：

你确定放在 access_by_lua 会对性能有影响？如果只是简单键值存取，redis性能正常，ngx-lua启用长连接的话，这个速度应该非常快，在整个http请求周期内占的比重相当小。

Lance

2014-07-18 16:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

这个确实是可行的，就是用ngx_shared当作nosql用，来存这些url，持久化的话可以再放一份到redis，
不知道我理解的对不对，这样用是不是合理。
但是我有个问题就是ngx_shared占用nginx内存，
如果资源比较多的话，占用的内存还比较多。

在 2014年7月18日星期五UTC+8下午3时25分26秒，smallfish写道：

2014-07-18 15:19 GMT+08:00 Jack Yan <yan...@gmail.com>:

ngx.shared.DICT这个有三个问题：
1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

不管哪种方案，初始化值都需要自己手动，这个属于业务范围，只有自己知道。

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。

使用 ngx.shared 的话，不需要这个变量了

3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

用 uri 作为 ngx.shared 的 key，也可以自己配置 expires

其实这里的用法就像普通使用 cache（memcache）一样，先判断是否有，有就干啥，没有有就执行啥啥。

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：
用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

--

--

--

lancelijade

有个办法可能可以，在 content_by_lua 里用 ngx.location.capture 发起本地跳转，内部用 proxy_pass 之类，然后回到 lua 判断返回值（这里不确定从缓存里出的结果和直接请求后端出的结果能否区分），lua 接到返回后可以直接发起 ngx.eof ，然后慢慢写 redis。

不过你确定你的需求是这样的吗？

Lance

2014-07-18 17:02 GMT+08:00 Lance <lance...@gmail.com>:

那你加这个redis记录的目的何在呢？如果已经有缓存，nginx 自己处理，如果没缓存，nginx 自己处理，你记下来，最后只是为了统计请求了多少次后端？

Lance

2014-07-18 16:58 GMT+08:00 Jack Yan <ya...@gmail.com>:

哦，对了，我所说的对性能的影响，不是别的意思，就是指那多余的redis请求。

在 2014年7月18日星期五UTC+8下午4时43分33秒，Lance Li写道：

你确定放在 access_by_lua 会对性能有影响？如果只是简单键值存取，redis性能正常，ngx-lua启用长连接的话，这个速度应该非常快，在整个http请求周期内占的比重相当小。

Lance

2014-07-18 16:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

这个确实是可行的，就是用ngx_shared当作nosql用，来存这些url，持久化的话可以再放一份到redis，
不知道我理解的对不对，这样用是不是合理。
但是我有个问题就是ngx_shared占用nginx内存，
如果资源比较多的话，占用的内存还比较多。

在 2014年7月18日星期五UTC+8下午3时25分26秒，smallfish写道：

2014-07-18 15:19 GMT+08:00 Jack Yan <yan...@gmail.com>:

ngx.shared.DICT这个有三个问题：
1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

不管哪种方案，初始化值都需要自己手动，这个属于业务范围，只有自己知道。

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。

使用 ngx.shared 的话，不需要这个变量了

3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

用 uri 作为 ngx.shared 的 key，也可以自己配置 expires

其实这里的用法就像普通使用 cache（memcache）一样，先判断是否有，有就干啥，没有有就执行啥啥。

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：
用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

--

--

--

yanvcl

redis里边记录的是已经缓存文件的url，我记录下来的原因，是因为以后如果我要批量清理缓存，

比如http://www.xxx.com/imga/，这个目录下所有的缓存都清理掉，我只需要去redis里边找到所有匹配这个url的key，

然后全部生成http://www.xxx.com/purge/imga/xxxx.jpg这样的单个资源文件的url，再去批量请求nginx来清理缓存。

在 2014年7月18日星期五UTC+8下午5时02分38秒，Lance Li写道：

那你加这个redis记录的目的何在呢？如果已经有缓存，nginx 自己处理，如果没缓存，nginx 自己处理，你记下来，最后只是为了统计请求了多少次后端？

Lance

2014-07-18 16:58 GMT+08:00 Jack Yan <yan...@gmail.com>:

哦，对了，我所说的对性能的影响，不是别的意思，就是指那多余的redis请求。

在 2014年7月18日星期五UTC+8下午4时43分33秒，Lance Li写道：

你确定放在 access_by_lua 会对性能有影响？如果只是简单键值存取，redis性能正常，ngx-lua启用长连接的话，这个速度应该非常快，在整个http请求周期内占的比重相当小。

Lance

2014-07-18 16:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

这个确实是可行的，就是用ngx_shared当作nosql用，来存这些url，持久化的话可以再放一份到redis，
不知道我理解的对不对，这样用是不是合理。
但是我有个问题就是ngx_shared占用nginx内存，
如果资源比较多的话，占用的内存还比较多。

在 2014年7月18日星期五UTC+8下午3时25分26秒，smallfish写道：

2014-07-18 15:19 GMT+08:00 Jack Yan <yan...@gmail.com>:

ngx.shared.DICT这个有三个问题：
1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

不管哪种方案，初始化值都需要自己手动，这个属于业务范围，只有自己知道。

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。

使用 ngx.shared 的话，不需要这个变量了

3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

用 uri 作为 ngx.shared 的 key，也可以自己配置 expires

其实这里的用法就像普通使用 cache（memcache）一样，先判断是否有，有就干啥，没有有就执行啥啥。

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：
用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

--

--

--

lancelijade

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_purge 这东西支持 *

Lance

2014-07-18 17:12 GMT+08:00 Jack Yan <ya...@gmail.com>:

redis里边记录的是已经缓存文件的url，我记录下来的原因，是因为以后如果我要批量清理缓存，
比如http://www.xxx.com/imga/，这个目录下所有的缓存都清理掉，我只需要去redis里边找到所有匹配这个url的key，
然后全部生成http://www.xxx.com/purge/imga/xxxx.jpg这样的单个资源文件的url，再去批量请求nginx来清理缓存。

在 2014年7月18日星期五UTC+8下午5时02分38秒，Lance Li写道：
那你加这个redis记录的目的何在呢？如果已经有缓存，nginx 自己处理，如果没缓存，nginx 自己处理，你记下来，最后只是为了统计请求了多少次后端？

Lance

2014-07-18 16:58 GMT+08:00 Jack Yan <yan...@gmail.com>:

哦，对了，我所说的对性能的影响，不是别的意思，就是指那多余的redis请求。

在 2014年7月18日星期五UTC+8下午4时43分33秒，Lance Li写道：

你确定放在 access_by_lua 会对性能有影响？如果只是简单键值存取，redis性能正常，ngx-lua启用长连接的话，这个速度应该非常快，在整个http请求周期内占的比重相当小。

Lance

2014-07-18 16:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

这个确实是可行的，就是用ngx_shared当作nosql用，来存这些url，持久化的话可以再放一份到redis，
不知道我理解的对不对，这样用是不是合理。
但是我有个问题就是ngx_shared占用nginx内存，
如果资源比较多的话，占用的内存还比较多。

在 2014年7月18日星期五UTC+8下午3时25分26秒，smallfish写道：

2014-07-18 15:19 GMT+08:00 Jack Yan <yan...@gmail.com>:

ngx.shared.DICT这个有三个问题：
1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

不管哪种方案，初始化值都需要自己手动，这个属于业务范围，只有自己知道。

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。

使用 ngx.shared 的话，不需要这个变量了

3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

用 uri 作为 ngx.shared 的 key，也可以自己配置 expires

其实这里的用法就像普通使用 cache（memcache）一样，先判断是否有，有就干啥，没有有就执行啥啥。

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：
用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

--

--

--

--

agentzh

Hello!

2014-07-17 23:37 GMT-07:00 Jack Yan:
> 大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
> 使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache
> proxy_pass）之前执行
> 但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
> 所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，

你是想把所有没有命中 nginx 自己的文件缓存的请求的 URI 都存入 redis?

如果是这样的话，你可以把你的 Lua 逻辑都放在 log_by_lua 里面，在这个上下文中 $upstream_cache_status
已有值。然后，你把满足条件的 URI 缓冲在一个你的 Lua 模块级别的 table 里面，然后从该 table 把 URI 分批写到
redis. 几个要点：

1. 尽量分批写 redis，而不是每请求都去写 redis（每请求都写 redis 显然要昂贵得多）. 如果没有绝对的实时性要求，可以在
Lua 级别缓冲 URI，比如缓冲最近的 100 条或 1000 条，然后再一次性刷到 redis. 缓冲的原理是基于
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

2. 再把多条记录成批写入 redis 时可以使用 redis pipelining 方式，见
https://github.com/openresty/lua-resty-redis#init_pipeline

3. 由于在 log_by_lua* 这样的上下文中不能直接使用 cosocket API（即 lua-resty-redis
不能直接使用），所以我们可以通过 ngx.timer.at(0, f) 创建 0 延时的 timer，再在你自己的 Lua timer
处理程序里面写 redis. 细节见
https://github.com/openresty/lua-nginx-module#ngxtimerat

我们有一个 Lua 库就是采取的类似的实现策略：https://github.com/cloudflare/lua-resty-logger-socket
可以参考它的 Lua 代码。

Regards,
-agentzh

yanvcl

嗯，谢谢，文档看过了，proxy_cache_purge这个指令在nginx1.5.7版本中添加：This directive appeared in version 1.5.7.

但是这是一个商业版本的，在nginx plus中是支持这个指令，并且支持curl -X PURGE -D – "http://www.example.com/*"

这样是否来批量清除缓存。我试过nginx.1.5.7版本，是不支持proxy_cache_purge指令的。

*) Feature: the "proxy_cache_revalidate", "fastcgi_cache_revalidate",

"scgi_cache_revalidate", and "uwsgi_cache_revalidate" directives.

这是1.5.7版本的一个changes，增加这几个指令，没有proxy_cache_purge的。

在 2014年7月18日星期五UTC+8下午5时16分42秒，Lance Li写道：

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_purge 这东西支持 *

Lance

2014-07-18 17:12 GMT+08:00 Jack Yan <yan...@gmail.com>:

redis里边记录的是已经缓存文件的url，我记录下来的原因，是因为以后如果我要批量清理缓存，
比如http://www.xxx.com/imga/，这个目录下所有的缓存都清理掉，我只需要去redis里边找到所有匹配这个url的key，
然后全部生成http://www.xxx.com/purge/imga/xxxx.jpg这样的单个资源文件的url，再去批量请求nginx来清理缓存。

在 2014年7月18日星期五UTC+8下午5时02分38秒，Lance Li写道：
那你加这个redis记录的目的何在呢？如果已经有缓存，nginx 自己处理，如果没缓存，nginx 自己处理，你记下来，最后只是为了统计请求了多少次后端？

Lance

2014-07-18 16:58 GMT+08:00 Jack Yan <yan...@gmail.com>:

哦，对了，我所说的对性能的影响，不是别的意思，就是指那多余的redis请求。

在 2014年7月18日星期五UTC+8下午4时43分33秒，Lance Li写道：

你确定放在 access_by_lua 会对性能有影响？如果只是简单键值存取，redis性能正常，ngx-lua启用长连接的话，这个速度应该非常快，在整个http请求周期内占的比重相当小。

Lance

2014-07-18 16:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

这个确实是可行的，就是用ngx_shared当作nosql用，来存这些url，持久化的话可以再放一份到redis，
不知道我理解的对不对，这样用是不是合理。
但是我有个问题就是ngx_shared占用nginx内存，
如果资源比较多的话，占用的内存还比较多。

在 2014年7月18日星期五UTC+8下午3时25分26秒，smallfish写道：

2014-07-18 15:19 GMT+08:00 Jack Yan <yan...@gmail.com>:

ngx.shared.DICT这个有三个问题：
1、这是个共享内存空间，nginx并不会自动设置一些变量，还是需要自己设置

不管哪种方案，初始化值都需要自己手动，这个属于业务范围，只有自己知道。

2、因此，我还是用$upstream_cache_status这个变量来赋值给这个共享内存，这样就还是没解决access代码执行在前，$upstream_cache_status变量设置在后的问题。

使用 ngx.shared 的话，不需要这个变量了

3、由于是共享内存，因此只要这个被设置过一次，比如为HIT，那么后续的所有url，无论是否真的缓存了，取这个值，都是一样的

用 uri 作为 ngx.shared 的 key，也可以自己配置 expires

其实这里的用法就像普通使用 cache（memcache）一样，先判断是否有，有就干啥，没有有就执行啥啥。

在 2014年7月18日星期五UTC+8下午2时43分38秒，smallfish写道：
用 ngx.shared.DICT 来作为判断？ https://github.com/openresty/lua-nginx-module/#ngxshareddict

--
smallfish http://chenxiaoyu.org

2014-07-18 14:37 GMT+08:00 Jack Yan <yan...@gmail.com>:

大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache proxy_pass）之前执行
但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，
因此，这样的话，access_by_lua_file阶段的代码，就没办法用这个变量了。
那么我把lua代码放到log阶段的话，又有问题了，就是log阶段没办法用ngx.socket.tcp API，也就是无法建立到redis的连接。
我问下，这有好的办法能解决这个矛盾的问题吗？我如何判断文件是否缓存，并且能根据缓存与否来存url到redis呢。
谢谢！

--

--

--

--

--

yanvcl

嗯，谢谢，我是想把所有nginx缓存了的静态文件url放到redis，为了之后通过redis读出这些url，来批量清理缓存。

你说的分批来写redis，这个策略比较好，还有就是在log_by_lua中通过吧cosocket API放到 Lua timer 里边执行，

这个我在论坛里边见过有人这么做，而且确实是可行的。

你的建议：

1、分批写redis

2、log_by_lua中的cosocket API放到lua timer中执行

谢谢了，我试试看

在 2014年7月19日星期六UTC+8上午2时40分26秒，agentzh写道：

Hello!

2014-07-17 23:37 GMT-07:00 Jack Yan:
> 大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
> 使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache
> proxy_pass）之前执行
> 但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
> 所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，

你是想把所有没有命中 nginx 自己的文件缓存的请求的 URI 都存入 redis?

如果是这样的话，你可以把你的 Lua 逻辑都放在 log_by_lua 里面，在这个上下文中 $upstream_cache_status
已有值。然后，你把满足条件的 URI 缓冲在一个你的 Lua 模块级别的 table 里面，然后从该 table 把 URI 分批写到
redis. 几个要点：

1. 尽量分批写 redis，而不是每请求都去写 redis（每请求都写 redis 显然要昂贵得多）. 如果没有绝对的实时性要求，可以在
Lua 级别缓冲 URI，比如缓冲最近的 100 条或 1000 条，然后再一次性刷到 redis. 缓冲的原理是基于
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

2. 再把多条记录成批写入 redis 时可以使用 redis pipelining 方式，见
https://github.com/openresty/lua-resty-redis#init_pipeline

3. 由于在 log_by_lua* 这样的上下文中不能直接使用 cosocket API（即 lua-resty-redis
不能直接使用），所以我们可以通过 ngx.timer.at(0, f) 创建 0 延时的 timer，再在你自己的 Lua timer
处理程序里面写 redis. 细节见
https://github.com/openresty/lua-nginx-module#ngxtimerat

我们有一个 Lua 库就是采取的类似的实现策略：https://github.com/cloudflare/lua-resty-logger-socket
可以参考它的 Lua 代码。

Regards,
-agentzh

lihang_net

有时间我试试这种方案，看看如何~

在 2014年7月19日星期六UTC+8上午2时40分26秒，agentzh写道：

Hello!

2014-07-17 23:37 GMT-07:00 Jack Yan:
> 大家好，最近我用nginx proxy_cache做静态缓存，那么我想凡是静态location的uri，我全部存入redis，
> 使用redis.lua模块，使用access_by_lua_file指令，肯定是没问题的，他在content（proxy_cache
> proxy_pass）之前执行
> 但是这样做的话，对性能有影响，而且我想，如果已经缓存过了的文件，就没必要再次访问redis了，
> 所以我想到的办法是根据一个变量$upstream_cache_status来判断，但是这个变量好像只在content阶段才会有值，

你是想把所有没有命中 nginx 自己的文件缓存的请求的 URI 都存入 redis?

如果是这样的话，你可以把你的 Lua 逻辑都放在 log_by_lua 里面，在这个上下文中 $upstream_cache_status
已有值。然后，你把满足条件的 URI 缓冲在一个你的 Lua 模块级别的 table 里面，然后从该 table 把 URI 分批写到
redis. 几个要点：

1. 尽量分批写 redis，而不是每请求都去写 redis（每请求都写 redis 显然要昂贵得多）. 如果没有绝对的实时性要求，可以在
Lua 级别缓冲 URI，比如缓冲最近的 100 条或 1000 条，然后再一次性刷到 redis. 缓冲的原理是基于
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

2. 再把多条记录成批写入 redis 时可以使用 redis pipelining 方式，见
https://github.com/openresty/lua-resty-redis#init_pipeline

3. 由于在 log_by_lua* 这样的上下文中不能直接使用 cosocket API（即 lua-resty-redis
不能直接使用），所以我们可以通过 ngx.timer.at(0, f) 创建 0 延时的 timer，再在你自己的 Lua timer
处理程序里面写 redis. 细节见
https://github.com/openresty/lua-nginx-module#ngxtimerat

我们有一个 Lua 库就是采取的类似的实现策略：https://github.com/cloudflare/lua-resty-logger-socket
可以参考它的 Lua 代码。

Regards,
-agentzh