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

Question

我运行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参数是否会影响缓存文件？

有任何想法吗？

Answer 1

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

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

该unlink(2)手册页,其中记录了系统调用使用的工具,如rm,内容如下:

该的unlink()函数删除路径从目录中名为链接和递减这是由链接引用的文件的链接数.如果该减量将文件的链接数减少为零,并且没有进程使文件打开,则回收与该文件关联的所有资源.如果一个或多个进程在删除最后一个链接时打开文件,则会删除该链接,但会删除该文件,直到所有对它的引用都已关闭为止.

根据系统的不同,您实际上仍可以完全恢复此类打开的文件而不会丢失任何数据,例如,请参阅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如果删除后紧急清除对您非常重要.