Nginx에서 업스트림 모듈을 사용하는 방법-엔진스-php.cn

업스트림 모듈 소개

nginx 모듈은 일반적으로 핸들러, 필터, 업스트림의 세 가지 범주로 나뉩니다. 이전 장에서 독자들은 이미 핸들러와 필터에 대해 배웠습니다. 이 두 가지 유형의 모듈을 사용하면 nginx는 모든 독립형 작업을 쉽게 완료할 수 있습니다.
업스트림 모듈을 사용하면 nginx가 단일 시스템의 한계를 뛰어넘어 네트워크 데이터의 수신, 처리 및 전달을 완료할 수 있습니다.
데이터 전달 기능은 nginx에 단일 머신 전반에 걸쳐 수평 처리 기능을 제공하여 nginx가 터미널 노드에 대해 단일 기능만 제공하는 제한에서 해방되고, 분할, 캡슐화 및 통합 기능을 가질 수 있도록 합니다. 네트워크 애플리케이션 수준.
데이터 전달은 nginx의 네트워크 애플리케이션 구축 기능의 핵심 구성 요소입니다. 물론 개발 비용 문제로 인해 네트워크 애플리케이션의 주요 구성 요소는 초기에 고급 프로그래밍 언어를 사용하여 개발되는 경우가 많습니다. 그러나 시스템이 특정 규모에 도달하고 성능에 더 중점을 두게 되면 필요한 성능 목표를 달성하기 위해 고급 언어로 개발된 구성 요소를 구조적으로 수정해야 합니다.

이때 수정 비용 측면에서 nginx의 업스트림 모듈은 본질적으로 빠르기 때문에 장점을 보여줍니다. 여담으로, nginx의 구성 시스템이 제공하는 계층적이고 느슨한 결합은 시스템을 상대적으로 높은 수준으로 확장할 수 있게 해줍니다.

업스트림 모듈 인터페이스

본질적으로 업스트림은 핸들러에 속하지만 자체 콘텐츠를 생성하지 않고 백엔드 서버에 요청하여 콘텐츠를 획득하므로 업스트림(upstream)이라고 합니다. 응답 콘텐츠를 요청하고 얻는 전체 프로세스가 nginx 내에 캡슐화되었으므로 업스트림 모듈은 요청 구성 및 응답 구문 분석과 같은 특정 작업을 완료하기 위해 여러 콜백 함수만 개발하면 됩니다.

업스트림 모듈 콜백 함수는 다음과 같습니다.

함수 이름	Description
create_request	업스트림 초기화 시 사용되는 백엔드 서버로 전송되는 요청 버퍼(버퍼 체인)를 생성합니다.
reinit_request	백엔드 서버가 실패하면 nginx는 다른 백엔드 서버를 시도합니다. nginx는 새 서버를 선택한 후 먼저 이 함수를 호출하여 업스트림 모듈의 작동 상태를 다시 초기화한 다음 업스트림을 다시 연결
process_header	하여 백엔드 서버에서 반환된 정보 헤더를 처리합니다. 소위 헤더는 HTTP 프로토콜의 헤더 부분이나 memcached 프로토콜의 응답 상태 부분과 같이 업스트림 서버와 통신하기 위한 프로토콜에 의해 지정됩니다.
abort_request	요청을 올립니다. 함수에 백엔드 서버 연결을 닫는 기능을 구현할 필요가 없습니다. 시스템이 자동으로 연결을 닫는 단계를 완료하므로 일반적으로 이 함수는 특정 작업을 수행하지 않습니다. 이 함수는 백엔드 서버와의 요청이 정상적으로 완료된 후에 호출됩니다. 이 함수는 abort_request와 마찬가지로 일반적으로 특정 작업을 수행하지 않습니다
input_filter	. nginx의 기본 input_filter는 수신된 콘텐츠를 버퍼 체인 ngx_chain으로 캡슐화합니다. 이 체인은 업스트림의 out_bufs 포인터 필드에 위치하므로 개발자는 이 포인터를 사용하여 모듈 외부의 백엔드 서버에서 반환된 텍스트 데이터를 얻을 수 있습니다. memcached 모듈은 자체 input_filter를 구현합니다. 이 모듈은 나중에 자세히 분석됩니다.
input_filter_init	입력 필터 컨텍스트를 초기화합니다. nginx의 기본 input_filter_init는 직접 반환됩니다
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가 효율적인 이유 중 하나입니다.