memcached 모듈 분석
memcache는 널리 사용되는 고성능 분산 캐시 시스템입니다. memcache는 HTTP 요청을 통해 Memcache에 액세스할 수 없도록 일련의 개인 통신 프로토콜을 정의합니다. 그러나 프로토콜 자체가 간단하고 효율적이며 Memcache가 널리 사용되므로 대부분의 최신 개발 언어와 플랫폼에서는 개발자가 Memcache를 쉽게 사용할 수 있도록 Memcache 지원을 제공합니다. nginx는 memcache에서 데이터를 읽는 기능을 제공하지만 memcache에 데이터를 쓰는 기능은 제공하지 않는 ngx_http_memcached 모듈을 제공합니다.
업스트림 모듈은 핸들러 모듈의 액세스 방법을 사용합니다.
동시에 업스트림 모듈의 명령 시스템 설계도 핸들러 모듈의 기본 규칙을 따릅니다. 모듈은 모듈을 구성한 후에만 실행됩니다.
그렇다면 업스트림 모듈의 특별한 점은 무엇인가요? 이는 업스트림 모듈의 처리 기능입니다. 업스트림 모듈의 처리 기능에 의해 수행되는 작업에는 고정된 프로세스가 포함됩니다. (memcached의 처리 기능 ngx_http_memcached_handler에서 memcached 모듈을 예로 들 수 있습니다.)
업스트림 데이터 구조 만들기 : ngx_http_upstream_t *u;
if (ngx_http_upstream_create(r) != NGX_OK) {
return NGX_HTTP_INTERNAL_SERVER_ERROR;
}
u = r->upstream;로그인 후 복사 모듈 태그와 스키마를 설정하세요. 이제 스키마는 로그에만 사용되고 태그는 buf_chain 관리에 사용됩니다: ngx_str_set(&u->schema, "memcached://");
u->output.tag = (ngx_buf_tag_t) &ngx_http_memcached_module; 로그인 후 복사 업스트림의 백엔드 서버 목록 데이터 구조 설정: mlcf = ngx_http_get_module_loc_conf(r, ngx_http_memcached_module);
u->conf = &mlcf->upstream; 로그인 후 복사 업스트림 콜백 기능 설정: u->create_request = ngx_http_memcached_create_request;
u->reinit_request = ngx_http_memcached_reinit_request;
u->process_header = ngx_http_memcached_process_header;
u->abort_request = ngx_http_memcached_abort_request;
u->finalize_request = ngx_http_memcached_finalize_request;
u->input_filter_init = ngx_http_memcached_filter_init;
u->input_filter = ngx_http_memcached_filter; 로그인 후 복사 업스트림 환경 데이터 구조 생성 및 설정: ctx = ngx_palloc(r->pool, sizeof(ngx_http_memcached_ctx_t));
if (ctx == NULL) {
return NGX_HTTP_INTERNAL_SERVER_ERROR;
}
ctx->request = r;
ngx_http_set_ctx(r, ctx, ngx_http_memcached_module);
u->input_filter_ctx = ctx;로그인 후 복사 업스트림 초기화 완료 및 작업 완료: r->main->count++;
ngx_http_upstream_init(r);
return NGX_DONE; 로그인 후 복사 이는 memcached만큼 간단하고 프록시 및 fastcgi만큼 복잡한 모든 업스트림 모듈에 해당됩니다.
이 6단계에서 다양한 업스트림 모듈 간의 가장 큰 차이점은 2, 3, 4, 5단계에서 나타납니다. 2단계와 4단계는 서로 다른 모듈에서 설정한 플래그와 사용되는 콜백 함수가 확실히 다릅니다. 5단계도 이해하기 어렵지 않습니다. 3단계만 약간 혼란스럽습니다. 백엔드 서버 목록을 얻을 때 모듈마다 전략이 매우 다릅니다. 일부는 memcached만큼 간단하고 명확하며 일부는 프록시만큼 논리적으로 복잡합니다. 6단계는 일반적으로 서로 다른 모듈 간에 일관됩니다. 개수를 1만큼 늘리고 NGX_DONE을 반환합니다.
nginx가 이러한 상황에 직면하면 현재 요청 처리가 종료된 것으로 간주하더라도 요청에 사용된 메모리 리소스를 해제하지 않으며 클라이언트와의 연결을 종료하지도 않습니다.
이것이 필요한 이유는 nginx가 업스트림 요청과 클라이언트 요청 사이에 일대일 관계를 설정했기 때문입니다. 이후에 ngx_event_pipe를 사용하여 업스트림 응답을 클라이언트에 다시 보낼 때 클라이언트 정보가 포함된 이러한 데이터도 사용됩니다. 구조.
업스트림 요청과 클라이언트 요청을 일대일로 바인딩합니다. 이 디자인에는 장점과 단점이 있습니다. 장점은 모듈 개발을 단순화하고 모듈 논리에 집중할 수 있다는 것입니다. 그러나 일대일 설계는 종종 복잡한 논리의 요구 사항을 충족할 수 없다는 단점도 있습니다. 콜백 함수: (memcached 모듈의 처리 기능을 예시로 사용) ngx_http_memcached_create_request: 설정된 내용에 따라 키를 생성하는 것은 매우 간단하며, 그 다음 "get $key"를 생성합니다. 요청하고 r ->upstream->request_bufs 내부에 넣으세요. ngx_http_memcached_reinit_request: 초기화가 필요하지 않습니다. ngx_http_memcached_abort_request: 추가 조치가 필요하지 않습니다. ngx_http_memcached_finalize_request: 추가 조치가 필요하지 않습니다. ngx_http_memcached_process_header: 모듈의 비즈니스 포커스 기능입니다. Memcache 프로토콜의 헤더 정보는 텍스트의 첫 번째 줄로 정의됩니다. 코드는 다음과 같습니다.
#define LF (u_char) '\n'
for (p = u->buffer.pos; p < u->buffer.last; p++) {
if (*p == LF) {
goto found;
}
}로그인 후 복사 버퍼로 읽어온 데이터에 LF(‘n’) 문자가 없는 경우 , 함수는 헤더가 완전히 읽혀지지 않았으므로 데이터를 계속 읽어야 함을 나타내는 NGX_AGAIN을 반환합니다. nginx는 새 데이터를 받은 후 이 함수를 다시 호출합니다. nginx는 백엔드 서버의 응답 헤더를 처리할 때 하나의 캐시만 사용하므로 모든 데이터가 이 캐시에 있으므로 헤더 정보를 구문 분석할 때 헤더 정보가 여러 캐시에 걸쳐 있다는 사실을 고려할 필요가 없습니다. 헤더가 너무 커서 이 캐시에 저장할 수 없는 경우 nginx는 클라이언트에 오류 메시지를 반환하고 캐시가 충분히 크지 않음을 나타내는 오류 로그를 기록합니다. ngx_http_memcached_process_header의 중요한 역할은 백엔드 서버에서 반환된 상태를 클라이언트에 반환된 상태로 변환하는 것입니다. 예: u->headers_in.content_length_n = ngx_atoof(start, p - start);
···
u->headers_in.status_n = 200;
u->state->status = 200;
···
u->headers_in.status_n = 404;
u->state->status = 404; 로그인 후 복사 u->state는 업스트림 관련 변수를 계산하는 데 사용됩니다. 예를 들어, u->state->status는 "upstream_status" 변수의 값을 계산하는 데 사용됩니다. u->headers_in은 클라이언트에 대한 응답에서 상태 코드로 반환됩니다. 그리고 u->headers_in.content_length_n은 클라이언트에 반환되는 응답의 길이를 설정합니다.
이 함수에서는 헤더 정보를 처리한 후 읽기 포인터 위치를 뒤로 이동해야 합니다. 그렇지 않으면 이 데이터도 클라이언트에 반환된 응답의 본문에 복사되어 잘못된 본문 내용이 발생하게 됩니다.
ngx_http_memcached_process_header 함수는 응답 헤더의 올바른 처리를 완료하고 NGX_OK를 반환해야 합니다. NGX_AGAIN이 반환되면 전체 데이터를 읽지 않았으며 백엔드 서버에서 데이터를 계속 읽어야 함을 의미합니다. NGX_DECLINED를 반환하는 것은 의미가 없습니다. 다른 반환 값은 오류 상태로 간주되며 nginx는 업스트림 요청을 종료하고 오류 메시지를 반환합니다.
ngx_http_memcached_filter_init: 백엔드 서버에서 수신한 콘텐츠 길이를 수정합니다. 왜냐하면 헤더를 처리할 때 길이의 이 부분이 추가되지 않기 때문입니다.
ngx_http_memcached_filter:
memcached 모듈은 텍스트 처리를 위한 콜백 함수가 포함된 보기 드문 모듈입니다.
memcached 모듈은 텍스트 끝의 CRLF "END" CRLF를 필터링해야 하기 때문에 자체 필터 콜백 기능을 구현했습니다.
텍스트를 처리한다는 실제 의미는 백엔드 서버에서 받은 텍스트의 유효한 내용을 ngx_chain_t에 캡슐화하여 u->out_bufs 끝에 추가한다는 것입니다.
nginx는 데이터를 복사하지 않지만 이러한 데이터 메모리 영역을 가리키도록 ngx_buf_t 데이터 구조를 설정한 다음 이러한 buf를 ngx_chain_t로 구성합니다. 이 구현은 대규모 메모리 재배치를 방지하며 nginx가 효율적인 이유 중 하나입니다.
| 
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
