首先说明一下应用方式，有两个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。
?
1
2
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。
?
1
2
3
4
5
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次的。
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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。
?
1
2
3
4
5
6
7
8
9
10
11
12
13
ngx_int_t
ngx_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
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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，请求就会被释放掉了。
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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计数跟踪内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://blog.csdn.net/wwyyxx26/article/details/122211554
声明： 猿站网有关资源均来自网络搜集与网友提供，任何涉及商业盈利目的的均不得使用，否则产生的一切后果将由您自己承担！ 本平台资源仅供个人学习交流、测试使用 所有内容请在下载后24小时内删除，制止非法恶意传播，不对任何下载或转载者造成的危害负任何法律责任！也请大家支持、购置正版！ 。本站一律禁止以任何方式发布或转载任何违法的相关信息访客发现请向站长举报，会员发帖仅代表会员个人观点，并不代表本站赞同其观点和对其真实性负责。本网站的资源部分来源于网络，如有侵权烦请发送邮件至：2697268773@qq.com进行处理。
