起首阐明一下应用方式，有两个nginx的模块，一个名为jtxy，另一个名为jtcmd。一个http哀求来了，会进入jtxy的模块处理，jtxy会创建出一个子哀求发送给jtcmd，jtcmd里处理呢又会创建出一个upstream流到我们的上游非http服务A来处理，A处理完成后得到效果，会把效果返回给jtcmd的子哀求，jtcmd的子哀求把效果返回给jtxy。就是如许一个流程，我们来跟踪一下一个请的count计数。
1、哀求到来，创建一个哀求，ngx_http_alloc_request里count被初始化为1
此时，count为1。
- r->main = r;
- r->count = 1;
2、jtxy模块里处理哀求时，调用了ngx_http_subrequest来创建一个子哀求，在ngx_http_subrequest里计数被加1。
此时，count为2复制代码
3、从一个模块出去(这里就是jtxy模块)，会调用ngx_http_finalize_request，在ngx_http_finalize_request里会计数减一。
此时，count为1。- if (r->content_handler) {
- r->write_event_handler = ngx_http_request_empty_handler;
- ngx_http_finalize_request(r, r->content_handler(r));
- return NGX_OK;
- }
4、然后进入了我们的子哀求jtcmd模块,，在这个模块里，假如发现本身是个子哀求((r!=r->main))，那么就应该把主哀求计数加一。这里标红强调这点是因为假如不加1，那么主哀求计数就会有题目，一会儿我们继续跟踪count的减1就会发现这个题目。
这里是jtxy发起的一个jtcmd子哀求这里的r和r->main并不雷同的，r是jtcmd，r->main就是jtxy。
此时，count为2。
同时因为我们子哀求jtcmd模块里使用了upstream，那么count是还需要在加1，但是我们使用时是ngx_http_read_client_request_body(r, ngx_http_upstream_init)，ngx_http_read_client_request_body里就已经加1了，以是，我们这里就不必本身来做这个加1了。
此时count为3。
各人可以看看《深入明白nginx》的5.1.5节的内容。对upstream流需要加1有解说。
以是呢，这里的count是加了2次的。- r->upstream->resolved->sockaddr = (struct sockaddr*)&backendSockAddr; r->upstream->resolved->socklen = sizeof(struct sockaddr_in); r->upstream->resolved->naddrs = 1; r->upstream->create_request = jtcmd_upstream_create_request; r->upstream->process_header = jtcmd_upstream_process_header; r->upstream->finalize_request = jtcmd_upstream_finalize_request; r->upstream->abort_request = jtcmd_upstream_abort_request; r->upstream->input_filter_init = ngx_http_jtcmd_filter_init; r->upstream->input_filter = ngx_http_jtcmd_filter; r->upstream->input_filter_ctx = jtcmdctx; //r->subrequest_in_memory = 1; if(r!=r->main) { r->main->count++; } ngx_int_t rc = ngx_http_read_client_request_body(r, ngx_http_upstream_init); if (rc == NGX_ERROR || rc > NGX_OK) { return rc; }
这里的r是子哀求，r->main是主哀求。同时还留意到，子哀求的count始终是0。- ngx_int_tngx_http_read_client_request_body(ngx_http_request_t *r, ngx_http_client_body_handler_pt post_handler){ size_t preread; ssize_t size; ngx_int_t rc; ngx_buf_t *b; ngx_chain_t out; ngx_http_request_body_t *rb; ngx_http_core_loc_conf_t *clcf; r->main->count++;
5、同第3一样，哀求的处理完后会调用ngx_http_finalize_request把计数减一，但是这里差异的是我们这里是一个子哀求，他这里有一步r = r->main;以是实际减时就减到了主哀求上去了，这个也是我们在4里红字阐明的要加1的缘故原由了。
此时，count为2- static void
- ngx_http_close_request(ngx_http_request_t *r, ngx_int_t rc)
- {
- ngx_connection_t *c;
-
- r = r->main;
- c = r->connection;
-
- ngx_log_debug2(NGX_LOG_DEBUG_HTTP, c->log, 0,
- "http request count:%d blk:%d", r->count, r->blocked);
-
- if (r->count == 0) {
- ngx_log_error(NGX_LOG_ALERT, c->log, 0, "http request count is zero");
- }
-
- r->count--;
6、然后呢，因为子哀求使用了upstream，因为这个缘故原由count加了一次1，那么当upstream竣事，就要减一次1。
此时count为1。
7、子哀求完成后，父哀求的回调方法接着处理，接下来就回到了主哀求模块jtxy里，这里在处理竣事后就会调用ngx_http_finalize_request来竣事掉这个哀求了，此时count为1，哀求就会被开释掉了。- void
- ngx_http_free_request(ngx_http_request_t *r, ngx_int_t rc)
- {
- ngx_log_t *log;
- ngx_pool_t *pool;
- struct linger linger;
- ngx_http_cleanup_t *cln;
- ngx_http_log_ctx_t *ctx;
- ngx_http_core_loc_conf_t *clcf;
-
- log = r->connection->log;
-
- ngx_log_debug0(NGX_LOG_DEBUG_HTTP, log, 0, "http close request");
-
- if (r->pool == NULL) {
- ngx_log_error(NGX_LOG_ALERT, log, 0, "http request already closed");
- return;
- }
总结
到此这篇关于nginx中一个哀求的count计数跟踪的文章就先容到这了,更多相干nginx哀求的count计数跟踪内容请搜索草根技能分享以前的文章或继续浏览下面的相干文章盼望各人以后多多支持草根技能分享！ | 
