缓存 – 清除nginx缓存文件并不总是有效

我运行一个nginx服务器PHP webservices API.我使用nginx的fastcgi_cache来缓存所有GET请求,当更新某些资源时,我清除一个或多个相关的缓存资源.

我用来执行此操作的方法是为要清除的每个资源计算nginx缓存文件名,然后删除该文件.在大多数情况下,这很有效.

但是,我发现有时候,即使删除了缓存文件,nginx仍然会从缓存中返回数据.

选择要删除的正确缓存文件不是问题 – 作为我测试的一部分,我删除了整个缓存目录,nginx仍然返回HIT响应

有人知道为什么会这样吗？是否可能涉及另一个缓存？例如,操作系统是否正在将缓存文件的缓存版本返回给nginx,因此nginx不知道它已被删除？

我在CentOS上运行它,并使用这个nginx配置(减去不相关的部分)：

user nginx;

# Let nginx figure out the best value
worker_processes auto;

events {
    worker_connections  10240;
    multi_accept        on;
    use                 epoll;
}

# Maximum number of open files should be at least worker_connections * 2
worker_rlimit_nofile 40960;

# Enable regex JIT compiler
pcre_jit on;

http {

    # TCP optimisation
    sendfile        on;
    tcp_nodelay     on;
    tcp_nopush      on;

    # Configure keep alive
    keepalive_requests  1000;
    keepalive_timeout   120s 120s;

    # Configure SPDY
    spdy_headers_comp 2;

    # Configure global PHP cache
    fastcgi_cache_path /var/nginx/cache levels=1:2 keys_zone=xxx:100m inactive=24h;

    # Enable open file caching
    open_file_cache max=10000 inactive=120s;
    open_file_cache_valid 120s;
    open_file_cache_min_uses 5;
    open_file_cache_errors off;

    server {
        server_name xxx;
        listen 8080;

        # Send all dynamic content requests to the main app handler
        if (!-f $document_root$uri) {

            rewrite ^/(.+)    /index.php/$1         last;
            rewrite ^/        /index.php            last;
        }

        # Proxy PHP requests to php-fpm
        location ~ [^/]\.php(/|$) {

            # Enable caching
            fastcgi_cache xxx;

            # Only cache GET and HEAD responses
            fastcgi_cache_methods GET HEAD;

            # Caching is off by default,an can only be enabled using Cache-Control response headers
            fastcgi_cache_valid 0;

            # Allow only one identical request to be forwarded (others will get a stale response)
            fastcgi_cache_lock on;

            # Define conditions for which stale content will be returned
            fastcgi_cache_use_stale error timeout invalid_header updating http_500 http_503;

            # Define cache key to uniquely identify cached objects
            fastcgi_cache_key "$scheme$request_method$host$request_uri";

            # Add a header to response to indicate cache results
            add_header X-Cache $upstream_cache_status;

            # Configure standard server parameters
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            include fastcgi_params;

            # php-fpm config
            fastcgi_param SCRIPT_URL        $fastcgi_path_info;
            fastcgi_param PATH_INFO         $fastcgi_path_info;
            fastcgi_param SCRIPT_FILENAME   $document_root$fastcgi_script_name;
            fastcgi_param REQUEST_SCHEME    $scheme;
            fastcgi_param REMOTE_USER       $remote_user;

            # Read buffer sizes
            fastcgi_buffer_size 128k;
            fastcgi_buffers 256 16k;
            fastcgi_busy_buffers_size 256k;
            fastcgi_temp_file_write_size 256k;

            # Keep connection open to enable keep-alive
            fastcgi_keep_conn on;

            # Proxy to PHP
            fastcgi_pass unix:/var/run/php-fpm/fpm.sock;
        }
    }
}

现在我看一下,open_file_cache参数是否会影响缓存文件？

有任何想法吗？

最佳答案

不,操作系统不会缓存文件.

但是,可能发生这种情况的原因是,在链接计数和打开文件的进程数都降为零之前,文件实际上并未完全删除.

unlink(2) manual page,其中记录了rm等工具使用的system call,内容如下：

The unlink() function removes the link named by path from its directory and decrements the link count of the file which was referenced by the link. If that decrement reduces the link count of the file to zero,and no process has the file open,then all resources associated with the file are reclaimed. If one or more processes have the file open when the last link is removed,the link is removed,but the removal of the file is delayed until all references to it have been closed.

根据系统的不同,您实际上仍可以完全恢复此类打开文件而不会丢失任何数据,例如,请参阅https://unix.stackexchange.com/questions/61820/how-can-i-access-a-deleted-open-file-on-linux-output-of-a-running-crontab-task.

因此,实际上,open_file_cache将有效地阻止您的删除在其缓存中仍具有相关文件描述符的进程中产生任何影响.如果删除后的紧急清除对您非常重要,则可能需要使用较短的open_file_cache_valid.