When we try to destroy more than 40k records at once, Nginx worker stops with 100% CPU usage.

strace shows that Nginx calls "brk(0); brk(bigval);" in infinite loop.

Very quick workaround: replace "if (entry->removed)" to "if(0)" at here, i.e., don't print removed records in HTML response.

What is the purpose of Redis in selective_cache_purge?

I see nginx caching goes to the disk.

Thank you.

Hello,

I'm seeing this too. It's easy to reproduce (redis_nginx_adapter is already installed btw):

tar xvf nginx-1.8.1.tar.gz

git clone https://github.com/wandenberg/nginx-selective-cache-purge-module.git

./configure --with-ld-opt=-Wl,-z,relro --with-cc-opt='-D_FORTIFY_SOURCE=2 -Ofast -march=native' --prefix=/usr/local/nginx --pid-path=/var/run --lock-path=/var/run --with-file-aio --with-ipv6 --with-rtsig_module --with-threads --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_stub_status_module --with-http_realip_module --with-http_secure_link_module --with-http_ssl_module --with-http_geoip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_gunzip_module --with-http_spdy_module --with-http_mp4_module --with-http_flv_module --with-pcre-jit --with-debug --add-module=./nginx-selective-cache-purge-module/

make -j8

cat /tmp/nginx.conf

daemon off;
events { use epoll; }
pid /var/run/nginx.pid;
error_log stderr debug;

http {
error_log stderr debug;
selective_cache_purge_redis_host localhost;
}

objs/nginx -c /tmp/nginx.conf [=][h:4130][pts/2][Fri 16-03-11 15:00]

2016/03/11 15:00:05 [notice] 28854#28854: using the "epoll" event method
2016/03/11 15:00:05 [debug] 28854#28854: counter: 00002B2A3B374080, 1
2016/03/11 15:00:05 [notice] 28854#28854: nginx/1.8.1
2016/03/11 15:00:05 [notice] 28854#28854: built by gcc 4.9.3 (Debian 4.9.3-5)
2016/03/11 15:00:05 [notice] 28854#28854: OS: Linux 4.1.0-2-amd64
2016/03/11 15:00:05 [notice] 28854#28854: sysctl(KERN_RTSIGMAX): 0
2016/03/11 15:00:05 [notice] 28854#28854: getrlimit(RLIMIT_NOFILE): 65536:65536
2016/03/11 15:00:05 [debug] 28854#28854: write: 4, 00007FFE64E49C90, 6, 0
2016/03/11 15:00:05 [debug] 28854#28854: setproctitle: "nginx: master process objs/nginx -c /tmp/nginx.conf"
2016/03/11 15:00:05 [notice] 28854#28854: start worker processes
2016/03/11 15:00:05 [debug] 28854#28854: channel 3:4
2016/03/11 15:00:05 [notice] 28854#28854: start worker process 28855
2016/03/11 15:00:05 [debug] 28854#28854: sigsuspend
2016/03/11 15:00:05 [debug] 28855#28855: notify eventfd: 6
2016/03/11 15:00:05 [debug] 28855#28855: eventfd: 7
2016/03/11 15:00:05 [debug] 28855#28855: malloc: 00000000011C34D0:6144
2016/03/11 15:00:05 [debug] 28855#28855: malloc: 00000000011D5E80:114688
2016/03/11 15:00:05 [debug] 28855#28855: malloc: 00000000011F1E90:53248
2016/03/11 15:00:05 [debug] 28855#28855: malloc: 00000000011FEEA0:53248
2016/03/11 15:00:05 [debug] 28855#28855: malloc: 00000000011B9210:80
2016/03/11 15:00:05 [debug] 28856#28856: setproctitle: "nginx: cache synchronizer"
2016/03/11 15:00:05 [alert] 28856#28856: io_destroy() failed (22: Invalid argument)
2016/03/11 15:00:05 [debug] 28856#28856: posix_memalign: 00000000011BE4B0:16384 @16
2016/03/11 15:00:05 [debug] 28856#28856: notify eventfd: 6
2016/03/11 15:00:05 [debug] 28856#28856: eventfd: 7
2016/03/11 15:00:05 [debug] 28856#28856: malloc: 00000000011C34D0:6144
2016/03/11 15:00:05 [debug] 28856#28856: malloc: 000000000120BEB0:114688
2016/03/11 15:00:05 [debug] 28856#28856: malloc: 0000000001227EC0:53248
2016/03/11 15:00:05 [debug] 28856#28856: malloc: 0000000001234ED0:53248
2016/03/11 15:00:05 [notice] 28856#28856: ngx_selective_cache_purge: sync process started
2016/03/11 15:00:05 [debug] 28856#28856: malloc: 00000000011B8E70:80
2016/03/11 15:00:05 [debug] 28856#28856: posix_memalign: 00000000011C4CE0:4096 @16
2016/03/11 15:00:05 [debug] 28856#28856: epoll timer: -1
2016/03/11 15:00:06 [notice] 28854#28854: signal 17 (SIGCHLD) received
2016/03/11 15:00:06 [alert] 28854#28854: worker process 28855 exited on signal 11
2016/03/11 15:00:06 [debug] 28854#28854: shmtx forced unlock
2016/03/11 15:00:06 [debug] 28854#28854: shmtx forced unlock
2016/03/11 15:00:06 [debug] 28854#28854: wake up, sigio 0
2016/03/11 15:00:06 [debug] 28854#28854: reap children
2016/03/11 15:00:06 [debug] 28854#28854: child: 0 28855 e:0 t:1 d:0 r:1 j:0
2016/03/11 15:00:06 [debug] 28854#28854: channel 3:4
2016/03/11 15:00:06 [notice] 28854#28854: start worker process 28857
2016/03/11 15:00:06 [debug] 28854#28854: sigsuspend
2016/03/11 15:00:06 [debug] 28857#28857: notify eventfd: 6
2016/03/11 15:00:06 [debug] 28857#28857: eventfd: 7
2016/03/11 15:00:06 [debug] 28857#28857: malloc: 00000000011C34D0:6144
2016/03/11 15:00:06 [debug] 28857#28857: malloc: 00000000011D5E80:114688
2016/03/11 15:00:06 [debug] 28857#28857: malloc: 00000000011F1E90:53248
2016/03/11 15:00:06 [debug] 28857#28857: malloc: 00000000011FEEA0:53248
2016/03/11 15:00:06 [debug] 28857#28857: malloc: 00000000011B9210:80
2016/03/11 15:00:06 [debug] 28857#28857: epoll add event: fd:4 op:1 ev:00002001
2016/03/11 15:00:06 [debug] 28857#28857: setproctitle: "nginx: worker process"
2016/03/11 15:00:06 [debug] 28857#28857: worker cycle
2016/03/11 15:00:06 [debug] 28857#28857: epoll timer: -1

What worries me is this segfault:

2016/03/11 15:00:06 [alert] 28854#28854: worker process 28855 exited on signal 11

Without the selective_cache_purge_redis_host log looks like this:

2016/03/11 15:17:14 [notice] 29418#29418: using the "epoll" event method
2016/03/11 15:17:14 [debug] 29418#29418: counter: 00002B084115F080, 1
2016/03/11 15:17:14 [notice] 29418#29418: nginx/1.8.1
2016/03/11 15:17:14 [notice] 29418#29418: built by gcc 4.9.3 (Debian 4.9.3-5)
2016/03/11 15:17:14 [notice] 29418#29418: OS: Linux 4.1.0-2-amd64
2016/03/11 15:17:14 [notice] 29418#29418: sysctl(KERN_RTSIGMAX): 0
2016/03/11 15:17:14 [notice] 29418#29418: getrlimit(RLIMIT_NOFILE): 65536:65536
2016/03/11 15:17:14 [debug] 29418#29418: write: 4, 00007FFEF5D004B0, 6, 0
2016/03/11 15:17:14 [debug] 29418#29418: setproctitle: "nginx: master process objs/nginx -c /tmp/nginx.conf"
2016/03/11 15:17:14 [notice] 29418#29418: start worker processes
2016/03/11 15:17:14 [debug] 29418#29418: channel 3:4
2016/03/11 15:17:14 [notice] 29418#29418: start worker process 29419
2016/03/11 15:17:14 [debug] 29418#29418: sigsuspend
2016/03/11 15:17:14 [debug] 29419#29419: notify eventfd: 6
2016/03/11 15:17:14 [debug] 29419#29419: eventfd: 7
2016/03/11 15:17:14 [debug] 29419#29419: malloc: 0000000001A294D0:6144
2016/03/11 15:17:14 [debug] 29419#29419: malloc: 0000000001A3BE80:114688
2016/03/11 15:17:14 [debug] 29419#29419: malloc: 0000000001A57E90:53248
2016/03/11 15:17:14 [debug] 29419#29419: malloc: 0000000001A64EA0:53248
2016/03/11 15:17:14 [debug] 29419#29419: epoll add event: fd:4 op:1 ev:00002001
2016/03/11 15:17:14 [debug] 29419#29419: setproctitle: "nginx: worker process"
2016/03/11 15:17:14 [debug] 29419#29419: worker cycle
2016/03/11 15:17:14 [debug] 29419#29419: epoll timer: -1

No segfault and no io_destroy error.

Regards,
Vedran

Hello,

I have tens of millions of files in cache and purge request causes 1000s of consecutive SCAN ... MATCH ... COUNT 100 queries being performed against redis which slows down nginx, making it completely saturate cpu cores during the purge (which is quite often).

Increasing COUNT from 100 to 1000000 in code resolves this issue (thus it only needs to execute a couple of queries), however when redis reply is lengthier (in my case it was over 1000 keys in a single reply) purge doesn't seem to work and I never get a reply from nginx. I noticed it fails to send subsequent queries to redis with a new cursor so I guess it just hangs after reading the first batch from redis. There are no errors in logs and it continues to issue SETEX commands to redis just fine.

There's one more thnig. If I reload nginx while the purge is being performed, old process ("worker process is shutting down") goes into loop (using 100% of cpu) filling the log with "[alert] 8677#0: *696760740 header already sent, ..." until I kill it (with sigkill, term doesn't work).

Regards,
Vedran

Is it possible to specify different selective_cache_purge_redis_database per server?

Why I needed this is that one of the servers has too many cached items, it slows everything down. If it is possible to use selective_cache_purge_redis_database per server, purging on other servers with fewer cached items could become faster.

Currently when I set different selective_cache_purge_redis_database for different server, I get this error message:

nginx: [emerg] "selective_cache_purge_redis_database" directive is duplicate in ...

Something like

if ($request_method = PURGE) {
    selective_cache_purge_query "$uri";
}

Hello

i try to build nginx with this module, but i get error which is in below. I've installed hiredis from apt and built redis_nginx_adapter from source and added configure parameters that are in below

./configure \
    --with-ld-opt='-L/usr/lib/ ' \
    --with-cc-opt='-I/usr/include/hiredis/ ' \
    --add-module=/path/to/nginx-selective-cache-purge-module

How can i solve this problem, could you please help me.

make -f objs/Makefile
make[1]: Entering directory '/usr/src/nginx/nginx-1.12.2'
cc -c -pipe  -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g -I/usr/include/hiredis/   -I src/core -I src/event -I src/event/modules -I src/os/unix -I /usr/src/nginx/nginx-selective-cache-purge-module-master/src -I /usr/src/nginx/nginx-selective-cache-purge-module-master/include -I objs -I src/http -I src/http/modules -I src/http/v2 -I /usr/src/nginx/ngx_http_accounting_module-master \
        -o objs/addon/src/ngx_selective_cache_purge_module.o \
        /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module.c
In file included from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module.c:3:0:
/usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module_redis.c: In function ‘open_context’:
/usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module_redis.c:153:119: error: passing argument 4 of ‘redis_nginx_open_context’ from incompatible pointer type [-Werror=incompatible-pointer-types]
 s_nginx_open_context((const char *) conf->redis_host.data, conf->redis_port, conf->redis_database, context);
                                                                                                    ^
In file included from /usr/src/nginx/nginx-selective-cache-purge-module-master/include/ngx_selective_cache_purge_module.h:11:0,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/include/ngx_selective_cache_purge_module_utils.h:4,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module_utils.c:1,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module.c:1:
/usr/local/include/redis_nginx_adapter.h:8:20: note: expected ‘const char *’ but argument is of type ‘redisAsyncContext ** {aka struct redisAsyncContext **}’
 redisAsyncContext *redis_nginx_open_context(const char *host, int port, int database, const char* password,
                    ^
In file included from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module.c:3:0:
/usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module_redis.c:153:16  error: too few arguments to function ‘redis_nginx_open_context’
         return redis_nginx_open_context((const char *) conf->redis_host.data, conf->redis_port, conf->redis_
                ^
In file included from /usr/src/nginx/nginx-selective-cache-purge-module-master/include/ngx_selective_cache_purge_module.h:11:0,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/include/ngx_selective_cache_purge_module_utils.h:4,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module_utils.c:1,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module.c:1:
/usr/local/include/redis_nginx_adapter.h:8:20: note: declared here
 redisAsyncContext *redis_nginx_open_context(const char *host, int port, int database, const char* password,
                    ^
In file included from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module.c:3:0:
/usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module_redis.c:155:113: error: passing argument 3 of ‘redis_nginx_open_context_unix’ from incompatible pointer type [-Werror=incompatible-pointer-types]
 n redis_nginx_open_context_unix((const char *) conf->redis_socket_path.data, conf->redis_database, context);
                                                                                                    ^
In file included from /usr/src/nginx/nginx-selective-cache-purge-module-master/include/ngx_selective_cache_purge_module.h:11:0,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/include/ngx_selective_cache_purge_module_utils.h:4,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module_utils.c:1,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module.c:1:
/usr/local/include/redis_nginx_adapter.h:9:20: note: expected ‘const char *’ but argument is of type ‘redisAsyncContext ** {aka struct redisAsyncContext **}’
 redisAsyncContext *redis_nginx_open_context_unix(const char *path, int database, const char* password, redis
                    ^
In file included from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module.c:3:0:
/usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module_redis.c:155:16  error: too few arguments to function ‘redis_nginx_open_context_unix’
         return redis_nginx_open_context_unix((const char *) conf->redis_socket_path.data, conf->redis_databa
                ^
In file included from /usr/src/nginx/nginx-selective-cache-purge-module-master/include/ngx_selective_cache_purge_module.h:11:0,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/include/ngx_selective_cache_purge_module_utils.h:4,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module_utils.c:1,
                 from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module.c:1:
/usr/local/include/redis_nginx_adapter.h:9:20: note: declared here
 redisAsyncContext *redis_nginx_open_context_unix(const char *path, int database, const char* password, redis
                    ^
In file included from /usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module.c:3:0:
/usr/src/nginx/nginx-selective-cache-purge-module-master/src/ngx_selective_cache_purge_module_redis.c:157:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
objs/Makefile:1511: recipe for target 'objs/addon/src/ngx_selective_cache_purge_module.o' failed
make[1]: *** [objs/addon/src/ngx_selective_cache_purge_module.o] Error 1
make[1]: Leaving directory '/usr/src/nginx/nginx-1.12.2'
Makefile:8: recipe for target 'build' failed
make: *** [build] Error 2

I'm using the following setup

   location ~ /purge(.*) {
        selective_cache_purge_query "$1";                                                 
    }        

   location ~ /mpurge {                                                                                                                                                            
        content_by_lua_block {                                                            
            local res = ngx.location.capture("/purge/*")
            ngx.print(res.status)
            ngx.print(res.body)
            return
        }
    }

It just hangs. I can only guess the module does not close the connection.

Hello !

First, thanks for your amazing project. I'm testing it with nginx 1.9.9 and everytime nginx starts, this error is written in the error_log :

[alert] 1514#0: io_destroy() failed (22: Invalid argument)

But the plugin seems to work fine at the moment. I still want to know what this mean but there is not enough information. What can I try to debug this ?

EDIT : more info about my configuration :

• I'm using http2
• I use a few other plugins for nginx, but this error happens only with this plugin.

Hello!

We use a module with alot of server's config's.
After nginx start we have in error.log:

ngx_slab_alloc() failed: no memory

Nginx stop immediately.

On the server we have 128G memory.

What's wrong?

Hello,

With the same minimal config file cache synchronizer process doesn't get started on nginx 1.10, same config works ok with 1.8:

$ tmp/nginx-1.8.1/objs/nginx -c /tmp/nginx.conf 2>&1 |egrep "selective|sync" 2016/06/29 12:01:52 [debug] 20943#20943: setproctitle: "nginx: cache synchronizer"
2016/06/29 12:01:52 [notice] 20943#20943: ngx_selective_cache_purge: sync process started
2016/06/29 12:01:52 [debug] 20943#20943: ngx_selective_cache_purge: start a cycle of sync for zone Z
2016/06/29 12:01:52 [debug] 20943#20943: ngx_selective_cache_purge: adding new entries
2016/06/29 12:01:52 [debug] 20943#20943: ngx_selective_cache_purge: finish a cycle of sync for zone Z, scheduling one more to process >= 0 files
^C

$ tmp/nginx-1.10.1/objs/nginx -c /tmp/nginx.conf 2>&1 |egrep "selective|sync"
2016/06/29 12:02:06 [debug] 20952#20952: setproctitle: "nginx: cache synchronizer"
^C

Looking deeper it appears synchronizer process crashes immediately and I managed to get a backtrace:

Core was generated bynginx: cache synchronizer '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000043477d in ngx_event_process_init (cycle=0xd16510) at src/event/ngx_event.c:609

609 for (m = 0; cycle->modules[m]; m++) {
(gdb) bt
#0 0x000000000043477d in ngx_event_process_init (cycle=0xd16510) at src/event/ngx_event.c:609
#1 0x00000000004b9965 in ngx_selective_cache_purge_run_sync () at ./nginx-selective-cache-purge-module//src/ngx_selective_cache_purge_module_sync.c:161
#2 0x00000000004b9c78 in ngx_selective_cache_purge_fork_sync_process () at ./nginx-selective-cache-purge-module//src/ngx_selective_cache_purge_module_sync.c:84
#3 0x00000000004b9e2e in ngx_selective_cache_purge_sync_memory_to_database () at ./nginx-selective-cache-purge-module//src/ngx_selective_cache_purge_module.c:405
#4 ngx_selective_cache_purge_init_worker (cycle=0xd12500) at ./nginx-selective-cache-purge-module//src/ngx_selective_cache_purge_module_setup.c:159
#5 0x000000000043cc6e in ngx_worker_process_init (cycle=cycle@entry=0xd12500, worker=worker@entry=0) at src/os/unix/ngx_process_cycle.c:900
#6 0x000000000043d1db in ngx_worker_process_cycle (cycle=cycle@entry=0xd12500, data=data@entry=0x0) at src/os/unix/ngx_process_cycle.c:734
#7 0x000000000043baaa in ngx_spawn_process (cycle=cycle@entry=0xd12500, proc=proc@entry=0x43d1c0 <ngx_worker_process_cycle>, data=data@entry=0x0, name=name@entry=0x4c142a "worker process",

respawn=respawn@entry=-3) at src/os/unix/ngx_process.c:198

#8 0x000000000043dc95 in ngx_start_worker_processes (cycle=cycle@entry=0xd12500, n=1, type=type@entry=-3) at src/os/unix/ngx_process_cycle.c:358
#9 0x000000000043e1d3 in ngx_master_process_cycle (cycle=cycle@entry=0xd12500) at src/os/unix/ngx_process_cycle.c:130
#10 0x0000000000414445 in main (argc=, argv=) at src/core/nginx.c:367`

Otherwise, module still works, redis gets filled and purge itself is working.

Thanks,
Vedran

Hi,
there is a hard-to-find bug in the module leading to segfaults on nginx reloads. Here is what happens:

1. In https://github.com/wandenberg/nginx-selective-cache-purge-module/blob/master/src/ngx_selective_cache_purge_module_setup.c#L365:L366 master initialiezes a shared memory structure with local (not shared) addresses
2. These addresses are valid in all forked workers
3. On reload master reinitializes the shared memory struct with new (changed) addresses and forks new workers
4. Old workers may still be handling their last requests and see the new addresses in shared memory which are invalid to them
5. .. segmentation fault

I started using nginx-selective-cache-purge-module on a fresh new environment and 10 hours later my cache size is about 20G with 450k files.

It worked like a charm on the beginning but the performance on purging cache was critically degraded and I am now experiencing a 15s response time for each purge request (each request purges only about 10-20 files).

The pattern I am using for the selective process is a simple prefix pattern, like foo*.

Is this an expected behavior? Is my cache size too big? I am planning on having a lot more cache files on the next weeks. It should be a problem?

nginx version: openresty/1.11.2.2
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.1t 3 May 2016
TLS SNI support enabled
configure arguments: --prefix=/usr/local/openresty/nginx --with-cc-opt=-O2 --add-module=../ngx_devel_kit-0.3.0 --add-module=../echo-nginx-module-0.60 --add-module=../xss-nginx-module-0.05 --add-module=../ngx_coolkit-0.2rc3 --add-module=../set-misc-nginx-module-0.31 --add-module=../form-input-nginx-module-0.12 --add-module=../encrypted-session-nginx-module-0.06 --add-module=../srcache-nginx-module-0.31 --add-module=../ngx_lua-0.10.7 --add-module=../ngx_lua_upstream-0.06 --add-module=../headers-more-nginx-module-0.32 --add-module=../array-var-nginx-module-0.05 --add-module=../memc-nginx-module-0.17 --add-module=../redis2-nginx-module-0.13 --add-module=../redis-nginx-module-0.3.7 --add-module=../rds-json-nginx-module-0.14 --add-module=../rds-csv-nginx-module-0.07 --with-ld-opt=-Wl,-rpath,/usr/local/openresty/luajit/lib --add-module=/nginx-selective-cache-purge-module --with-http_ssl_module

It would be nice to implement purging by tags (ala CloudFlare and Varnish' bans). The mechanism is explained here:

• https://blog.cloudflare.com/introducing-a-powerful-way-to-purge-cache-on-cloudflare-purge-by-cache-tag/
• http://www.smashingmagazine.com/2014/04/cache-invalidation-strategies-with-varnish-cache/

I am trying to implement this via globs, but this is not the most efficient way.

As we know , nginx maintains cached content by cache keys zone as index. I think your module will copy cache keys in each zone to redis database, is that correct?
Really got confused by this module . You create a new process named cache synchronizer which is in a loop of dealing events. Is it responsible for copying cache key zone item to redis in the meanwhile of handling a request? What kind of events of a request will be used to make cache keys zone and Redis data synchronized ?