服务器 发布日期:2024/12/29 浏览次数:1
nginx的共享内存,是其能够实现高性能的主要原因之一,而其主要是用于对文件的缓存。本文首先会讲解共享内存的使用方式,然后会讲解nginx是如何实现共享内存的管理的。
1. 使用示例
nginx声明共享内存的指令为:
proxy_cache_path /Users/Mike/nginx-cache levels=1:2 keys_zone=one:10m max_size=10g inactive=60m use_temp_path=off;
这里只是声明的一个名称为one,最大可用内存为10g的共享内存。这里面各个参数的含义如下:
2. 工作原理
共享内存的管理工作主要分为如下图所示的几个部分:
可以看到,其主要分为初始化、共享内存的管理、共享内存的加载和共享内存的使用等几个方面。在初始化的过程中,首先会解析proxy_cache_path指令,然后分别启动cache manager和cache loader进程;这里cache manager进程主要是进行共享内存的管理的,其主要是通过LRU算法清除过期数据,或者当资源紧张时强制删除部分未被引用的内存数据;而cache loader进程的主要工作是在nginx启动之后,读取文件存储目录中已有的文件,将其加载到共享内存中;而共享内存的使用主要是在处理请求完成之后对响应数据的缓存,这一部分的内容将在后面的文章中进行讲解,本文主要讲解前面三部分的工作原理。
按照上面的划分,共享内存的管理主要可以分为三个部分(共享内存的使用将在后面进行讲解)。如下是这三个部分的处理流程的示意图:
从上面的流程图中可以看出,在主流程中,主要进行了解析proxy_cache_path指令、启动cache manager进程和启动cache loader进程的工作。而在cache manager进程中,主要工作则分为两部分:1. 检查队列尾部元素是否过期,如果过期并且引用数为0,则删除该元素和该元素对应的文件;2. 检查当前共享内存是否资源紧张,如果资源紧张,则删除所有引用数为0的元素及其文件,无论其是否过期。在cache loader进程的处理流程中,主要是通过递归的方式遍历存储文件的目录及其子目录中的文件,然后将这些文件加载到共享内存中。需要注意的是,cache manager进程在每次遍历完所有的共享内存块之后会进入下一次循环,而cache loader进程在nginx启动之后60s的时刻执行一次,然后就会退出该进程。
3. 源码解读
3.1 proxy_cache_path指令解析
对于nginx各个指令的解析,其都会在相应的模块中定义一个ngx_command_t结构体,该结构体中有一个set方法指定了解析当前指令所使用的方法。如下是proxy_cache_path所对应的ngx_command_t结构体的定义:
static ngx_command_t ngx_http_proxy_commands[] = { { ngx_string("proxy_cache_path"), // 指定了当前指令的名称 // 指定了当前指令的使用位置,即http模块,并且指定了当前模块的参数个数,这里是必须大于等于2 NGX_HTTP_MAIN_CONF|NGX_CONF_2MORE, // 指定了set()方法所指向的方法 ngx_http_file_cache_set_slot, NGX_HTTP_MAIN_CONF_OFFSET, offsetof(ngx_http_proxy_main_conf_t, caches), &ngx_http_proxy_module } }
可以看到,该指令所使用的解析方法是ngx_http_file_cache_set_slot(),这里我们直接阅读该方法的源码:
char *ngx_http_file_cache_set_slot(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) { char *confp = conf; off_t max_size; u_char *last, *p; time_t inactive; ssize_t size; ngx_str_t s, name, *value; ngx_int_t loader_files, manager_files; ngx_msec_t loader_sleep, manager_sleep, loader_threshold, manager_threshold; ngx_uint_t i, n, use_temp_path; ngx_array_t *caches; ngx_http_file_cache_t *cache, **ce; cache = ngx_pcalloc(cf->pool, sizeof(ngx_http_file_cache_t)); if (cache == NULL) { return NGX_CONF_ERROR; } cache->path = ngx_pcalloc(cf->pool, sizeof(ngx_path_t)); if (cache->path == NULL) { return NGX_CONF_ERROR; } // 初始化各个属性的默认值 use_temp_path = 1; inactive = 600; loader_files = 100; loader_sleep = 50; loader_threshold = 200; manager_files = 100; manager_sleep = 50; manager_threshold = 200; name.len = 0; size = 0; max_size = NGX_MAX_OFF_T_VALUE; // 示例配置:proxy_cache_path /Users/Mike/nginx-cache levels=1:2 keys_zone=one:10m max_size=10g inactive=60m use_temp_path=off; // 这里的cf->args->elts中存储了解析proxy_cache_path指令时,其包含的各个token项, // 所谓的token项,指的就是使用空格分隔的字符片段 value = cf->args->elts; // value[1]就是配置的第一个参数,也即cache文件会保存的根路径 cache->path->name = value[1]; if (cache->path->name.data[cache->path->name.len - 1] == '/') { cache->path->name.len--; } if (ngx_conf_full_name(cf->cycle, &cache->path->name, 0) != NGX_OK) { return NGX_CONF_ERROR; } // 从第三个参数开始进行解析 for (i = 2; i < cf->args->nelts; i++) { // 如果第三个参数是以"levels="开头,则解析levels子参数 if (ngx_strncmp(value[i].data, "levels=", 7) == 0) { p = value[i].data + 7; // 计算开始解析的其实位置 last = value[i].data + value[i].len; // 计算最后一个字符的位置 // 开始解析1:2 for (n = 0; n < NGX_MAX_PATH_LEVEL && p < last; n++) { if (*p > '0' && *p < '3') { // 获取当前的参数值,比如需要解析的1和2 cache->path->level[n] = *p++ - '0'; cache->path->len += cache->path->level[n] + 1; if (p == last) { break; } // 如果当前字符是冒号,则继续下一个字符的解析; // 这里的NGX_MAX_PATH_LEVEL值为3,也就是说levels参数后最多接3级子目录 if (*p++ == ':' && n < NGX_MAX_PATH_LEVEL - 1 && p < last) { continue; } goto invalid_levels; } goto invalid_levels; } if (cache->path->len < 10 + NGX_MAX_PATH_LEVEL) { continue; } invalid_levels: ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid \"levels\" \"%V\"", &value[i]); return NGX_CONF_ERROR; } // 如果当前的参数是以"use_temp_path="开头,则解析use_temp_path参数,该参数值为on或者off, // 表示当前缓存文件是否首先存入临时文件夹中,最后再写入到目标文件夹中,如果为off则直接存入目标文件夹 if (ngx_strncmp(value[i].data, "use_temp_path=", 14) == 0) { // 如果为on,则标记use_temp_path为1 if (ngx_strcmp(&value[i].data[14], "on") == 0) { use_temp_path = 1; // 如果为off,则标记use_temp_path为0 } else if (ngx_strcmp(&value[i].data[14], "off") == 0) { use_temp_path = 0; // 如果都不止,则返回解析异常 } else { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid use_temp_path value \"%V\", " "it must be \"on\" or \"off\"", &value[i]); return NGX_CONF_ERROR; } continue; } // 如果参数是以"keys_zone="开头,则解析keys_zone参数。该参数的形式如keys_zone=one:10m, // 这里的one是一个名称,以供给后续的location配置使用,而10m则是一个大小, // 表示供给存储key的缓存大小 if (ngx_strncmp(value[i].data, "keys_zone=", 10) == 0) { name.data = value[i].data + 10; p = (u_char *) ngx_strchr(name.data, ':'); if (p) { // 计算name的长度,name记录了当前的缓存区的名称,也即这里的one name.len = p - name.data; p++; // 解析所指定的size大小 s.len = value[i].data + value[i].len - p; s.data = p; // 对大小进行解析,会将指定的大小最终转换为字节数,这里的字节数必须大于8191 size = ngx_parse_size(&s); if (size > 8191) { continue; } } ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid keys zone size \"%V\"", &value[i]); return NGX_CONF_ERROR; } // 如果参数是以"inactive="开头,则解析inactive参数。该参数的形式如inactive=60m, // 表示缓存的文件在多长时间没有访问之后将会过期 if (ngx_strncmp(value[i].data, "inactive=", 9) == 0) { s.len = value[i].len - 9; s.data = value[i].data + 9; // 对时间进行解析,最终将转换为以秒为单位的时间长度 inactive = ngx_parse_time(&s, 1); if (inactive == (time_t) NGX_ERROR) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid inactive value \"%V\"", &value[i]); return NGX_CONF_ERROR; } continue; } // 如果参数是以"max_size="开头,则解析max_size参数。该参数的形式如max_size=10g, // 表示当前缓存能够使用的最大内存空间 if (ngx_strncmp(value[i].data, "max_size=", 9) == 0) { s.len = value[i].len - 9; s.data = value[i].data + 9; // 对解析得到的值进行转换,最终将以字节数为单位 max_size = ngx_parse_offset(&s); if (max_size < 0) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid max_size value \"%V\"", &value[i]); return NGX_CONF_ERROR; } continue; } // 如果参数是以"loader_files="开头,则解析loader_files参数。该参数形如loader_files=100, // 表示在启动nginx的时候默认会加载多少个缓存目录中的文件到缓存中 if (ngx_strncmp(value[i].data, "loader_files=", 13) == 0) { // 解析loader_files参数的值 loader_files = ngx_atoi(value[i].data + 13, value[i].len - 13); if (loader_files == NGX_ERROR) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid loader_files value \"%V\"", &value[i]); return NGX_CONF_ERROR; } continue; } // 如果参数是以"loader_sleep="开头,则解析loader_sleep参数。该参数形如loader_sleep=10s, // 表示每次加载一个文件之后休眠多长时间,然后再加载下一个文件 if (ngx_strncmp(value[i].data, "loader_sleep=", 13) == 0) { s.len = value[i].len - 13; s.data = value[i].data + 13; // 对loader_sleep的值进行转换,这里是以毫秒数为单位 loader_sleep = ngx_parse_time(&s, 0); if (loader_sleep == (ngx_msec_t) NGX_ERROR) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid loader_sleep value \"%V\"", &value[i]); return NGX_CONF_ERROR; } continue; } // 如果参数是以"loader_threshold="开头,则解析loader_threshold参数,该参数形如loader_threshold=10s, // 表示每次加载一个文件能够使用的最长时间 if (ngx_strncmp(value[i].data, "loader_threshold=", 17) == 0) { s.len = value[i].len - 17; s.data = value[i].data + 17; // 对loader_threshold的值进行解析并且转换,最终是以毫秒数为单位 loader_threshold = ngx_parse_time(&s, 0); if (loader_threshold == (ngx_msec_t) NGX_ERROR) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid loader_threshold value \"%V\"", &value[i]); return NGX_CONF_ERROR; } continue; } // 如果参数是以"manager_files="开头,则解析manager_files参数,该参数形如manager_files=100, // 表示当缓存空间用尽时,将会以LRU算法将文件进行删除,不过每次迭代最多删除manager_files所指定的文件数 if (ngx_strncmp(value[i].data, "manager_files=", 14) == 0) { // 解析manager_files参数值 manager_files = ngx_atoi(value[i].data + 14, value[i].len - 14); if (manager_files == NGX_ERROR) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid manager_files value \"%V\"", &value[i]); return NGX_CONF_ERROR; } continue; } // 如果参数是以"manager_sleep="开头,则解析manager_sleep参数,该参数形如manager_sleep=1s, // 表示每次迭代完成之后将会休眠manager_sleep参数所指定的时长 if (ngx_strncmp(value[i].data, "manager_sleep=", 14) == 0) { s.len = value[i].len - 14; s.data = value[i].data + 14; // 对manager_sleep所指定的值进行解析 manager_sleep = ngx_parse_time(&s, 0); if (manager_sleep == (ngx_msec_t) NGX_ERROR) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid manager_sleep value \"%V\"", &value[i]); return NGX_CONF_ERROR; } continue; } // 如果参数是以"manager_threshold="开头,则解析manager_threshold参数,该参数形如manager_threshold=2s, // 表示每次清除文件的迭代的最长耗时不能超过该参数所指定的值 if (ngx_strncmp(value[i].data, "manager_threshold=", 18) == 0) { s.len = value[i].len - 18; s.data = value[i].data + 18; // 解析manager_threshold参数值,并且将其转换为以毫秒数为单位的值 manager_threshold = ngx_parse_time(&s, 0); if (manager_threshold == (ngx_msec_t) NGX_ERROR) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid manager_threshold value \"%V\"", &value[i]); return NGX_CONF_ERROR; } continue; } ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "invalid parameter \"%V\"", &value[i]); return NGX_CONF_ERROR; } if (name.len == 0 || size == 0) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "\"%V\" must have \"keys_zone\" parameter", &cmd->name); return NGX_CONF_ERROR; } // 这里的cache->path->manager和cache->path->loader的值为两个函数,需要注意的是, // 在nginx启动之后,会启动两个单独的进程,一个cache manager,一个cache loader,其中cache manager // 将会在一个循环中不断的为每个共享内存执行cache->path->manager所指定的方法, // 从而实现对缓存进行清理。而另一个进程cache loader则会在nginx启动之后60s的时候只执行一次, // 执行的方法就是cache->path->loader所指定的方法, // 该方法的主要作用是加载已经存在的文件数据到当前的共享内存中 cache->path->manager = ngx_http_file_cache_manager; cache->path->loader = ngx_http_file_cache_loader; cache->path->data = cache; cache->path->conf_file = cf->conf_file->file.name.data; cache->path->line = cf->conf_file->line; cache->loader_files = loader_files; cache->loader_sleep = loader_sleep; cache->loader_threshold = loader_threshold; cache->manager_files = manager_files; cache->manager_sleep = manager_sleep; cache->manager_threshold = manager_threshold; // 将当前的path添加到cycle中,后续会对这些path进行检查,如果path不存在,则会创建相应的路径 if (ngx_add_path(cf, &cache->path) != NGX_OK) { return NGX_CONF_ERROR; } // 把当前共享内存添加到cf->cycle->shared_memory所指定的共享内存列表中 cache->shm_zone = ngx_shared_memory_add(cf, &name, size, cmd->post); if (cache->shm_zone == NULL) { return NGX_CONF_ERROR; } if (cache->shm_zone->data) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "duplicate zone \"%V\"", &name); return NGX_CONF_ERROR; } // 这里指定了每个共享内存的初始化方法,该方法在master进程启动的时候会被执行 cache->shm_zone->init = ngx_http_file_cache_init; cache->shm_zone->data = cache; cache->use_temp_path = use_temp_path; cache->inactive = inactive; cache->max_size = max_size; caches = (ngx_array_t *) (confp + cmd->offset); ce = ngx_array_push(caches); if (ce == NULL) { return NGX_CONF_ERROR; } *ce = cache; return NGX_CONF_OK; }
从上面的代码可以看出,在proxy_cache_path方法中,主要是初始化了一个ngx_http_file_cache_t结构体。而该结构体中的各个属性,则是通过解析proxy_cache_path的各个参数来进行的。
3.2 cache manager与cache loader进程启动
nginx程序的入口方法是nginx.c的main()方法,如果开启了master-worker进程模式,那么最后就会进入ngx_master_process_cycle()方法,该方法首先会启动worker进程,以接收客户端的请求;然后会分别启动cache manager和cache loader进程;最后进入一个无限循环中,以处理用户在命令行向nginx发送的指令。如下是cache manager和cache loader进程启动的源码:
void ngx_master_process_cycle(ngx_cycle_t *cycle) { ... // 获取核心模块的配置 ccf = (ngx_core_conf_t *) ngx_get_conf(cycle->conf_ctx, ngx_core_module); // 启动各个worker进程 ngx_start_worker_processes(cycle, ccf->worker_processes, NGX_PROCESS_RESPAWN); // 启动cache进程 ngx_start_cache_manager_processes(cycle, 0); ... }
对于cache manager和cache loader进程的启动,可以看到,其主要是在ngx_start_cache_manager_processes()方法中,如下是该方法的源码:
static void ngx_start_cache_manager_processes(ngx_cycle_t *cycle, ngx_uint_t respawn) { ngx_uint_t i, manager, loader; ngx_path_t **path; ngx_channel_t ch; manager = 0; loader = 0; path = ngx_cycle->paths.elts; for (i = 0; i < ngx_cycle->paths.nelts; i++) { // 查找是否有任何一个path指定了manager为1 if (path[i]->manager) { manager = 1; } // 查找是否有任何一个path指定了loader为1 if (path[i]->loader) { loader = 1; } } // 如果没有任何一个path的manager指定为1,则直接返回 if (manager == 0) { return; } // 创建一个进程以执行ngx_cache_manager_process_cycle()方法中所执行的循环,需要注意的是, // 在回调ngx_cache_manager_process_cycle方法时,这里传入的第二个参数是ngx_cache_manager_ctx ngx_spawn_process(cycle, ngx_cache_manager_process_cycle, &ngx_cache_manager_ctx, "cache manager process", respawn "cache loader process", respawn "htmlcode">// 启动cache manager进程 ngx_spawn_process(cycle, ngx_cache_manager_process_cycle, &ngx_cache_manager_ctx, "cache manager process", respawn "cache loader process", respawn "htmlcode">// 这里的ngx_cache_manager_process_handler指定了当前cache manager进程将会执行的方法, // cache manager process则指定了该进程的名称,而最后的0表示当前进程在启动之后间隔多长时间才会执行 // ngx_cache_manager_process_handler()方法,这里是立即执行 static ngx_cache_manager_ctx_t ngx_cache_manager_ctx = { ngx_cache_manager_process_handler, "cache manager process", 0 }; // 这里的ngx_cache_loader_process_handler指定了当前cache loader进程将会执行的方法, // 其会在cache loader进程启动后60秒之后才会执行ngx_cache_loader_process_handler()方法 static ngx_cache_manager_ctx_t ngx_cache_loader_ctx = { ngx_cache_loader_process_handler, "cache loader process", 60000 };可以看到,这两个结构体主要是分别定义了cache manager和cache loader两个进程的不同行为。下面我们来看一下ngx_cache_manager_process_cycle()方法是如何调用这两个方法的:
static void ngx_cache_manager_process_cycle(ngx_cycle_t *cycle, void *data) { ngx_cache_manager_ctx_t *ctx = data; void *ident[4]; ngx_event_t ev; ngx_process = NGX_PROCESS_HELPER; // 当前进程主要是用于处理cache manager和cache loader工作的,因而其不需要进行socket的监听,因而这里需要将其关闭 ngx_close_listening_sockets(cycle); /* Set a moderate number of connections for a helper process. */ cycle->connection_n = 512; // 对当前的进程进行初始化,主要是设置一些参数属性,并且在最后为当前进行设置监听channel[1]句柄的事件,从而接收master进程的消息 ngx_worker_process_init(cycle, -1); ngx_memzero(&ev, sizeof(ngx_event_t)); // 对于cache manager,这里的handler指向的是ngx_cache_manager_process_handler()方法, // 对于cache loader,这里的handler指向的是ngx_cache_loader_process_handler()方法 ev.handler = ctx->handler; ev.data = ident; ev.log = cycle->log; ident[3] = (void *) -1; // cache模块不需要使用共享锁 ngx_use_accept_mutex = 0; ngx_setproctitle(ctx->name); // 把当前事件添加到事件队列中,事件的延迟时间为ctx->delay,对于cache manager,该值为0, // 而对于cache loader,该值为60s。 // 需要注意的是,在当前事件的处理方法中,ngx_cache_manager_process_handler()如果处理完了当前事件, // 会将当前事件再次添加到事件队列中,从而实现定时处理的功能;而对于 // ngx_cache_loader_process_handler()方法,其处理完一次之后,并不会将当前事件 // 再次添加到事件队列中,因而相当于当前事件只会执行一次,然后cache loader进程就会退出 ngx_add_timer(&ev, ctx->delay); for ( ;; ) { // 如果master将当前进程标记为terminate或者quit状态,则退出进程 if (ngx_terminate || ngx_quit) { ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "exiting"); exit(0); } // 如果master进程发出了reopen消息,则重新打开所有的缓存文件 if (ngx_reopen) { ngx_reopen = 0; ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "reopening logs"); ngx_reopen_files(cycle, -1); } // 执行事件队列中的事件 ngx_process_events_and_timers(cycle); } }上面的代码中,首先创建了一个事件对象,ev.handler = ctx->handler;指定了该事件所需要处理的逻辑,也即上面两个结构体中的第一个参数所对应的方法;然后将该事件添加到事件队列中,即ngx_add_timer(&ev, ctx->delay);,需要注意的是,这里的第二个参数就是上面两个结构体中所指定的第三个参数,也就是说这里是以事件的延迟时间的方式来控制hander()方法的执行时间的;最后,在一个无限for循环中,通过ngx_process_events_and_timers()方法来不断检查事件队列的事件,并且处理事件。
3.3 cache manager进程处理逻辑
对于cache manager处理的流程,通过上面的讲解可以看出,其是在其所定义的cache manager结构体中的ngx_cache_manager_process_handler()方法中进行的。如下是该方法的源码:
static void ngx_cache_manager_process_handler(ngx_event_t *ev) { ngx_uint_t i; ngx_msec_t next, n; ngx_path_t **path; next = 60 * 60 * 1000; path = ngx_cycle->paths.elts; for (i = 0; i < ngx_cycle->paths.nelts; i++) { // 这里的manager方法指向的是ngx_http_file_cache_manager()方法 if (path[i]->manager) { n = path[i]->manager(path[i]->data); next = (n <= next) "htmlcode">static ngx_msec_t ngx_http_file_cache_manager(void *data) { // 这里的ngx_http_file_cache_t结构体是解析proxy_cache_path配置项得到的 ngx_http_file_cache_t *cache = data; off_t size; time_t wait; ngx_msec_t elapsed, next; ngx_uint_t count, watermark; cache->last = ngx_current_msec; cache->files = 0; // 这里的ngx_http_file_cache_expire()方法在一个无限循环中,不断检查缓存队列尾部是否有过期的 // 共享内存,如果存在,则将其以及其所对应的文件进行删除 next = (ngx_msec_t) ngx_http_file_cache_expire(cache) * 1000; // next是ngx_http_file_cache_expire()方法的返回值,该方法只有在两种情况下才会返回0: // 1. 当删除的文件个数超过了manager_files指定的文件个数时; // 2. 当删除各个文件的总耗时超过了manager_threshold所指定的总时长时; // 如果next为0,则说明完成了一个批次的缓存清理工作,此时是需要休眠一段时间然后再进行下一次的清理工作, // 这个休眠的时长就是manager_sleep所指定的值。也就是说这里的next的值实际上就是下一次 // 执行缓存清理工作的等待时长 if (next == 0) { next = cache->manager_sleep; goto done; } for ( ;; ) { ngx_shmtx_lock(&cache->shpool->mutex); // 这里的size指的是当前缓存所使用的总大小 // count指定了当前缓存中的文件个数 // watermark则表示水位,其为总共能够存储的文件个数的7/8 size = cache->sh->size; count = cache->sh->count; watermark = cache->sh->watermark; ngx_shmtx_unlock(&cache->shpool->mutex); ngx_log_debug3(NGX_LOG_DEBUG_HTTP, ngx_cycle->log, 0, "http file cache size: %O c:%ui w:%i", size, count, (ngx_int_t) watermark); // 如果当前的缓存所使用的内存大小小于能够使用的最大大小并且缓存文件个数小于水位, // 说明还可以继续存储缓存文件,则跳出循环 if (size < cache->max_size && count < watermark) { break; } // 走到这里说明共享内存可用资源不足 // 这里主要是强制删除当前队列中未被引用的文件,无论其是否过期 wait = ngx_http_file_cache_forced_expire(cache); // 计算下次执行的时间 if (wait > 0) { next = (ngx_msec_t) wait * 1000; break; } // 如果当前nginx已经退出或者终止,则跳出循环 if (ngx_quit || ngx_terminate) { break; } // 如果当前删除的文件个数超过了manager_files所指定的个数,则跳出循环, // 并且指定距离下次清理工作所需要休眠的时间 if (++cache->files >= cache->manager_files) { next = cache->manager_sleep; break; } ngx_time_update(); elapsed = ngx_abs((ngx_msec_int_t) (ngx_current_msec - cache->last)); // 如果当前删除动作的耗时超过了manager_threshold所指定的时长,则跳出循环, // 并且指定距离下次清理工作所需要休眠的时间 if (elapsed >= cache->manager_threshold) { next = cache->manager_sleep; break; } } done: elapsed = ngx_abs((ngx_msec_int_t) (ngx_current_msec - cache->last)); ngx_log_debug3(NGX_LOG_DEBUG_HTTP, ngx_cycle->log, 0, "http file cache manager: %ui e:%M n:%M", cache->files, elapsed, next); return next; }在ngx_http_file_cache_manager()方法中,首先会进入ngx_http_file_cache_expire()方法,该方法的主要作用是检查当前共享内存队列尾部的元素是否过期,如果过期,则根据其引用次数和是否正在被删除而判断是否需要将该元素以及该元素对应的磁盘文件进行删除。在进行这个检查之后,然后会进入一个无限for循环,这里循环的主要目的是检查当前的共享内存是否资源比较紧张,也即是否所使用的内存超过了max_size定义的最大内存,或者是当前所缓存的文件总数超过了总文件数的7/8。如果这两个条件有一个达到了,就会尝试进行强制清除缓存文件,所谓的强制清除就是删除当前共享内存中所有被引用数为0的元素及其对应的磁盘文件。这里我们首先阅读ngx_http_file_cache_expire()方法:
static time_t ngx_http_file_cache_expire(ngx_http_file_cache_t *cache) { u_char *name, *p; size_t len; time_t now, wait; ngx_path_t *path; ngx_msec_t elapsed; ngx_queue_t *q; ngx_http_file_cache_node_t *fcn; u_char key[2 * NGX_HTTP_CACHE_KEY_LEN]; ngx_log_debug0(NGX_LOG_DEBUG_HTTP, ngx_cycle->log, 0, "http file cache expire"); path = cache->path; len = path->name.len + 1 + path->len + 2 * NGX_HTTP_CACHE_KEY_LEN; name = ngx_alloc(len + 1, ngx_cycle->log); if (name == NULL) { return 10; } ngx_memcpy(name, path->name.data, path->name.len); now = ngx_time(); ngx_shmtx_lock(&cache->shpool->mutex); for ( ;; ) { // 如果当前nginx已经退出了,或者终止了,则跳出当前循环 if (ngx_quit || ngx_terminate) { wait = 1; break; } // 如果当前的共享内存队列为空的,则跳出当前循环 if (ngx_queue_empty(&cache->sh->queue)) { wait = 10; break; } // 获取队列的最后一个元素 q = ngx_queue_last(&cache->sh->queue); // 获取队列的节点 fcn = ngx_queue_data(q, ngx_http_file_cache_node_t, queue); // 计算节点的过期时间距离当前时间的时长 wait = fcn->expire - now; // 如果当前节点没有过期,则退出当前循环 if (wait > 0) { wait = wait > 10 "http file cache expire: #%d %d %02xd%02xd%02xd%02xd", fcn->count, fcn->exists, fcn->key[0], fcn->key[1], fcn->key[2], fcn->key[3]); // 这里的count表示当前的节点被引用的次数,如果其引用次数为0,则直接删除该节点 if (fcn->count == 0) { // 这里的主要动作是将当前的节点从队列中移除,并且删除该节点对应的文件 ngx_http_file_cache_delete(cache, q, name); goto next; } // 如果当前节点正在被删除,那么当前进程就可以不用对其进行处理 if (fcn->deleting) { wait = 1; break; } // 走到这里,说明当前节点已经过期了,但是引用数大于0,并且没有进程正在删除该节点 // 这里计算的是该节点进行hex计算后文件的名称 p = ngx_hex_dump(key, (u_char *) &fcn->node.key, sizeof(ngx_rbtree_key_t)); len = NGX_HTTP_CACHE_KEY_LEN - sizeof(ngx_rbtree_key_t); (void) ngx_hex_dump(p, fcn->key, len); // 由于当前节点在时间上已经过期了,但是有请求正在引用该节点,并且没有进程正在删除该节点, // 说明该节点应该被保留,因而这里尝试将该节点从队列尾部删除,并且为其重新计算下次的过期时间, // 然后将其插入到队列头部 ngx_queue_remove(q); fcn->expire = ngx_time() + cache->inactive; ngx_queue_insert_head(&cache->sh->queue, &fcn->queue); ngx_log_error(NGX_LOG_ALERT, ngx_cycle->log, 0, "ignore long locked inactive cache entry %*s, count:%d", (size_t) 2 * NGX_HTTP_CACHE_KEY_LEN, key, fcn->count); next: // 这里是队列中的最后一个节点被删除,并且对应的文件也被删除之后才会执行的逻辑 // 这里的cache->files记录了当前已经处理的节点数,manager_files的含义在于, // 在进行LRU算法强制清除文件时,最多会清除该参数所指定的文件个数,默认为100。 // 因而这里如果cache->files如果大于等于manager_files,则跳出循环 if (++cache->files >= cache->manager_files) { wait = 0; break; } // 更新当前nginx缓存的时间 ngx_time_update(); // elapsed等于当前删除动作的总耗时 elapsed = ngx_abs((ngx_msec_int_t) (ngx_current_msec - cache->last)); // 如果总耗时超过了manager_threshold所指定的值,则跳出当前循环 if (elapsed >= cache->manager_threshold) { wait = 0; break; } } // 释放当前的锁 ngx_shmtx_unlock(&cache->shpool->mutex); ngx_free(name); return wait; }可以看到,这里的主要处理逻辑是首先会火嘴队列尾部的元素,根据LRU算法,队列尾部的元素是最有可能过期的元素,因而只需要检查该元素即可。然后检查该元素是否过期,如果没有过期,则退出当前方法,否则检查当前元素是否引用数为0,也就是说如果当前元素已经过期,并且引用数为0,则直接删除该元素及其对应的磁盘文件。如果当前元素引用数不为0,则会检查其是否正在被删除,需要注意的是,如果一个元素正在被删除,那么删除进程是会将其引用数置为1的,以防止其他的进程也进行删除操作。如果其正在被删除,则当前进程不会处理该元素,如果没有被删除,则当前进程会尝试将该元素从队列尾部移动到队列头部,这么做的主要原因在于,虽然元素已经过期,但是其引用数不为0,并且没有进程正在删除该元素,那么说明该元素还是一个活跃元素,因而需要将其移动到队列头部。
下面我们来看一下,当资源比较紧张时,cache manager是如何强制清除元素的,如下是ngx_http_file_cache_forced_expire()方法的源码:
static time_t ngx_http_file_cache_forced_expire(ngx_http_file_cache_t *cache) { u_char *name; size_t len; time_t wait; ngx_uint_t tries; ngx_path_t *path; ngx_queue_t *q; ngx_http_file_cache_node_t *fcn; ngx_log_debug0(NGX_LOG_DEBUG_HTTP, ngx_cycle->log, 0, "http file cache forced expire"); path = cache->path; len = path->name.len + 1 + path->len + 2 * NGX_HTTP_CACHE_KEY_LEN; name = ngx_alloc(len + 1, ngx_cycle->log); if (name == NULL) { return 10; } ngx_memcpy(name, path->name.data, path->name.len); wait = 10; tries = 20; ngx_shmtx_lock(&cache->shpool->mutex); // 不断遍历队列中的每个节点 for (q = ngx_queue_last(&cache->sh->queue); q != ngx_queue_sentinel(&cache->sh->queue); q = ngx_queue_prev(q)) { // 获取当前节点的数据 fcn = ngx_queue_data(q, ngx_http_file_cache_node_t, queue); ngx_log_debug6(NGX_LOG_DEBUG_HTTP, ngx_cycle->log, 0, "http file cache forced expire: #%d %d %02xd%02xd%02xd%02xd", fcn->count, fcn->exists, fcn->key[0], fcn->key[1], fcn->key[2], fcn->key[3]); // 如果当前节点的引用数为0,则直接删除该节点 if (fcn->count == 0) { ngx_http_file_cache_delete(cache, q, name); wait = 0; } else { // 进行下一个节点的尝试,如果有连续的20个节点的引用数都大于0,则会跳出当前循环 if (--tries) { continue; } wait = 1; } break; } ngx_shmtx_unlock(&cache->shpool->mutex); ngx_free(name); return wait; }可以看到,这里的处理逻辑比较简单,主要是从队列尾部开始往前依次检查队列中的元素的引用次数是否为0,如果为0,则直接删除,然后检查下一个元素。如果不为0,则检查下一个元素,如此往复。这里需要注意的是,如果检查总共有20次元素正在被引用过程中,则跳出当前循环。
3.4 cache loader进程处理逻辑
前面已经讲到,cache loader的主要处理流程在ngx_cache_loader_process_handler()方法中,如下是该方法的主要处理逻辑:
static void ngx_cache_loader_process_handler(ngx_event_t *ev) { ngx_uint_t i; ngx_path_t **path; ngx_cycle_t *cycle; cycle = (ngx_cycle_t *) ngx_cycle; path = cycle->paths.elts; for (i = 0; i < cycle->paths.nelts; i++) { if (ngx_terminate || ngx_quit) { break; } // 这里的loader方法指向的是ngx_http_file_cache_loader()方法 if (path[i]->loader) { path[i]->loader(path[i]->data); ngx_time_update(); } } // 加载完成后退出当前流程 exit(0); }这里cache loader与cache manager的处理主流程是非常相似的,主要是通过调用各个路径的loader()方法进行数据加载的,而loader()方法的具体实现方法也是在proxy_cache_path配置项解析的时候定义的,具体的定义如下(在3.1节最后一部分):
cache->path->loader = ngx_http_file_cache_loader;
这里我们继续阅读ngx_http_file_cache_loader()方法的源码:
static void ngx_http_file_cache_loader(void *data) { ngx_http_file_cache_t *cache = data; ngx_tree_ctx_t tree; // 如果已经加载完成或者正在加载,则直接返回 if (!cache->sh->cold || cache->sh->loading) { return; } // 尝试加锁 if (!ngx_atomic_cmp_set(&cache->sh->loading, 0, ngx_pid)) { return; } ngx_log_debug0(NGX_LOG_DEBUG_HTTP, ngx_cycle->log, 0, "http file cache loader"); // 这里的tree就是加载的一个主要流程对象,加载的过程是通过递归的方式进行的 tree.init_handler = NULL; // 封装了加载单个文件的操作 tree.file_handler = ngx_http_file_cache_manage_file; // 在加载一个目录之前的操作,这里主要是检查当前目录有没有操作权限 tree.pre_tree_handler = ngx_http_file_cache_manage_directory; // 在加载一个目录之后的操作,这里实际上是一个空方法 tree.post_tree_handler = ngx_http_file_cache_noop; // 这里主要是处理特殊文件,即既不是文件也不是文件夹的文件,这里主要是删除了该文件 tree.spec_handler = ngx_http_file_cache_delete_file; tree.data = cache; tree.alloc = 0; tree.log = ngx_cycle->log; cache->last = ngx_current_msec; cache->files = 0; // 开始通过递归的方式遍历指定目录下的所有文件,然后按照上面定义的方法对其进行处理,也即加载到共享内存中 if (ngx_walk_tree(&tree, &cache->path->name) == NGX_ABORT) { cache->sh->loading = 0; return; } // 标记加载状态 cache->sh->cold = 0; cache->sh->loading = 0; ngx_log_error(NGX_LOG_NOTICE, ngx_cycle->log, 0, "http file cache: %V %.3fM, bsize: %uz", &cache->path->name, ((double) cache->sh->size * cache->bsize) / (1024 * 1024), cache->bsize); }在加载过程中,首先将目标加载目录封装到一个ngx_tree_ctx_t结构体中,并且为其指定加载文件所使用的方法。最终的加载逻辑主要是在ngx_walk_tree()方法中进行的,而整个加载过程也是通过递归来实现的。如下是ngx_walk_tree()方法的实现原理:
ngx_int_t ngx_walk_tree(ngx_tree_ctx_t *ctx, ngx_str_t *tree) { void *data, *prev; u_char *p, *name; size_t len; ngx_int_t rc; ngx_err_t err; ngx_str_t file, buf; ngx_dir_t dir; ngx_str_null(&buf); ngx_log_debug1(NGX_LOG_DEBUG_CORE, ctx->log, 0, "walk tree \"%V\"", tree); // 打开目标目录 if (ngx_open_dir(tree, &dir) == NGX_ERROR) { ngx_log_error(NGX_LOG_CRIT, ctx->log, ngx_errno, ngx_open_dir_n " \"%s\" failed", tree->data); return NGX_ERROR; } prev = ctx->data; // 这里传入的alloc是0,因而不会进入当前分支 if (ctx->alloc) { data = ngx_alloc(ctx->alloc, ctx->log); if (data == NULL) { goto failed; } if (ctx->init_handler(data, prev) == NGX_ABORT) { goto failed; } ctx->data = data; } else { data = NULL; } for ( ;; ) { ngx_set_errno(0); // 读取当前子目录中的内容 if (ngx_read_dir(&dir) == NGX_ERROR) { err = ngx_errno; if (err == NGX_ENOMOREFILES) { rc = NGX_OK; } else { ngx_log_error(NGX_LOG_CRIT, ctx->log, err, ngx_read_dir_n " \"%s\" failed", tree->data); rc = NGX_ERROR; } goto done; } len = ngx_de_namelen(&dir); name = ngx_de_name(&dir); ngx_log_debug2(NGX_LOG_DEBUG_CORE, ctx->log, 0, "tree name %uz:\"%s\"", len, name); // 如果当前读取到的是.,则表示其为当前目录,跳过该目录 if (len == 1 && name[0] == '.') { continue; } // 如果当前读取到的是..,则表示其为返回上一级目录的标识,跳过该目录 if (len == 2 && name[0] == '.' && name[1] == '.') { continue; } file.len = tree->len + 1 + len; // 更新可用的缓存大小 if (file.len + NGX_DIR_MASK_LEN > buf.len) { if (buf.len) { ngx_free(buf.data); } buf.len = tree->len + 1 + len + NGX_DIR_MASK_LEN; buf.data = ngx_alloc(buf.len + 1, ctx->log); if (buf.data == NULL) { goto failed; } } p = ngx_cpymem(buf.data, tree->data, tree->len); *p++ = '/'; ngx_memcpy(p, name, len + 1); file.data = buf.data; ngx_log_debug1(NGX_LOG_DEBUG_CORE, ctx->log, 0, "tree path \"%s\"", file.data); if (!dir.valid_info) { if (ngx_de_info(file.data, &dir) == NGX_FILE_ERROR) { ngx_log_error(NGX_LOG_CRIT, ctx->log, ngx_errno, ngx_de_info_n " \"%s\" failed", file.data); continue; } } // 如果当前读取到的是一个文件,则调用ctx->file_handler()加载该文件的内容 if (ngx_de_is_file(&dir)) { ngx_log_debug1(NGX_LOG_DEBUG_CORE, ctx->log, 0, "tree file \"%s\"", file.data); // 设置文件的相关属性 ctx->size = ngx_de_size(&dir); ctx->fs_size = ngx_de_fs_size(&dir); ctx->access = ngx_de_access(&dir); ctx->mtime = ngx_de_mtime(&dir); if (ctx->file_handler(ctx, &file) == NGX_ABORT) { goto failed; } // 如果当前读取到的是一个目录,则首先调用设置的pre_tree_handler()方法,然后调用 // ngx_walk_tree()方法,递归的读取子目录,最后调用设置的post_tree_handler()方法 } else if (ngx_de_is_dir(&dir)) { ngx_log_debug1(NGX_LOG_DEBUG_CORE, ctx->log, 0, "tree enter dir \"%s\"", file.data); ctx->access = ngx_de_access(&dir); ctx->mtime = ngx_de_mtime(&dir); // 应用读取目录的前置逻辑 rc = ctx->pre_tree_handler(ctx, &file); if (rc == NGX_ABORT) { goto failed; } if (rc == NGX_DECLINED) { ngx_log_debug1(NGX_LOG_DEBUG_CORE, ctx->log, 0, "tree skip dir \"%s\"", file.data); continue; } // 递归的读取当前目录 if (ngx_walk_tree(ctx, &file) == NGX_ABORT) { goto failed; } ctx->access = ngx_de_access(&dir); ctx->mtime = ngx_de_mtime(&dir); // 应用读取目录的后置逻辑 if (ctx->post_tree_handler(ctx, &file) == NGX_ABORT) { goto failed; } } else { ngx_log_debug1(NGX_LOG_DEBUG_CORE, ctx->log, 0, "tree special \"%s\"", file.data); if (ctx->spec_handler(ctx, &file) == NGX_ABORT) { goto failed; } } } failed: rc = NGX_ABORT; done: if (buf.len) { ngx_free(buf.data); } if (data) { ngx_free(data); ctx->data = prev; } if (ngx_close_dir(&dir) == NGX_ERROR) { ngx_log_error(NGX_LOG_CRIT, ctx->log, ngx_errno, ngx_close_dir_n " \"%s\" failed", tree->data); } return rc; }从上面的处理流程可以看出,真正的加载文件的逻辑在ngx_http_file_cache_manage_file()方法中,如下是该方法的源码:
static ngx_int_t ngx_http_file_cache_manage_file(ngx_tree_ctx_t *ctx, ngx_str_t *path) { ngx_msec_t elapsed; ngx_http_file_cache_t *cache; cache = ctx->data; // 将文件添加到共享内存中 if (ngx_http_file_cache_add_file(ctx, path) != NGX_OK) { (void) ngx_http_file_cache_delete_file(ctx, path); } // 如果加载的文件个数超过了loader_files指定的个数,则休眠一段时间 if (++cache->files >= cache->loader_files) { ngx_http_file_cache_loader_sleep(cache); } else { // 更新当前缓存的时间 ngx_time_update(); // 计算当前加载炒作的耗时 elapsed = ngx_abs((ngx_msec_int_t) (ngx_current_msec - cache->last)); ngx_log_debug1(NGX_LOG_DEBUG_HTTP, ngx_cycle->log, 0, "http file cache loader time elapsed: %M", elapsed); // 如果加载操作耗时超过了loader_threshold所指定的时间,则休眠指定的时间 if (elapsed >= cache->loader_threshold) { ngx_http_file_cache_loader_sleep(cache); } } return (ngx_quit || ngx_terminate) "color: #ff0000">4. 小结
本文首先讲解了nginx共享内存的使用方式以及各个参数的具体含义,然后对共享内存的实现原理进行了讲解,最后着重讲解了共享内存的初始化、cache manager和cache loader的工作原理。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。
在去年的5月23日,借助Intel Bridge Technology以及Intel Celadon两项技术的驱动,Intel为PC用户带来了Android On Windows(AOW)平台,并携手国内软件公司腾讯共同推出了腾讯应用宝电脑版,将Windows与安卓两大生态进行了融合,PC的使用体验随即被带入到了一个全新的阶段。