3. 현재 실행 단계 에서 데이터 공 유 를 요청 합 니 다.

10.1 절 과 10.2 절 에 서 는 전역 캐 시 시스템 을 소개 합 니 다. 현재 요청 에 만 설 치 된 캐 시 가 있 습 니까? 즉, 어떤 데 이 터 는 요청 한 단계 마다 캐 시 가 있 지만 요청 이 끝나 면 캐 시가 사라 집 니 다.
예 를 들 어 rewrite 단계 에서 캐 시 데 이 터 를 1 개 만 들 기 를 요청 합 니 다. 다음 단계 (예 를 들 어 content 단계) 에서 이 캐 시 데 이 터 를 가 져 올 수 있 지만 이 데 이 터 는 요청 이 완료 되면 사용 되 지 않 습 니 다. 요청 이 끝 난 후에 지 울 수 있 습 니 다.
이 캐 시 는 주로 다음 과 같은 상황 에 사용 되 며, NgxLua 에 서 는 Lua API 의 실행 이 단계 적 으로 제한 되 어 있 으 므 로, Lua API 를 실행 할 수 없 는 단계 에서 Lua API 명령 을 사용 해 데 이 터 를 생 성 해 야 할 경우 아까 소개 한 캐 시 방식 을 이용 해 다른 단계 에서 데 이 터 를 처리 하고 캐 시 할 수 있 으 며, 이 데이터 가 필요 한 단계 에서 이 캐 시 를 호출 하면 된다.여기에 필요 한 캐 시 명령 은 ngx. ctx 입 니 다.
10.3.1 ngx. ctx 의 사용
환경: initworker_by_lua、set_by_lua、rewrite_by_lua、access_by_lua、 content_by_lua、header_filter_by_lua、body_filter_by_lua、log_by_lua、ngx.timer.、balancer_by_lua 의미: ngx. ctx 는 Lua 의 table 형식 으로 Lua 기반 환경 데 이 터 를 캐 시 합 니 다. 이 캐 시 는 요청 이 끝 난 후에 비 워 집 니 다. Nginx 에서 set 명령 과 같은 효과 입 니 다.예시:

 rewrite_by_lua_block {
        --  1 test  
        ngx.ctx.test = 'nginx'
        ngx.ctx.test_1 = {a=1,b=2}

    }
    access_by_lua_block {
        --  test
        ngx.ctx.test = ngx.ctx.test .. ' hello'
    }
    content_by_lua_block {
        --  test   test_1  a    
        ngx.say(ngx.ctx.test)
        ngx.say("a: ",ngx.ctx.test_1["a"])
    }
    header_filter_by_lua_block {
        --       
        ngx.header["test"] = ngx.ctx.test .. ' world!'
    }
}

위 설정 실행 결 과 는 다음 과 같 습 니 다.

# curl -i  'http://testnginx.com/'
HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Mon, 18 Jun 2018 05:07:15 GMT
Content-Type: application/octet-stream
Transfer-Encoding: chunked
Connection: keep-alive
test: nginx hello world!

nginx hello
a: 1

실행 결 과 를 통 해 알 수 있 듯 이 ngx. ctx 의 데 이 터 는 Lua 의 모든 실행 단계 에서 읽 거나 쓸 수 있 으 며 table 형식의 데 이 터 를 저장 할 수 있 습 니 다.
10.3.2 하위 요청 과 내부 방향 을 바 꾸 는 캐 시 차이
ngx. ctx 는 하위 요청 과 내부 재 설정 에서 의 사용 방법 에 차이 가 있 습 니 다.하위 요청 에서 ngx. ctx. 의 데 이 터 를 수정 하 는 것 은 주 요청 에서 ngx. ctx. 에 대응 하 는 데이터 에 영향 을 주지 않 습 니 다. 하위 요청 을 수행 하 는 ngx. location. capture, ngx. location. capture 와 같은 버 전 을 유지 합 니 다.multi、echo_위치 등 명령 시;내부 재 설정 에서 데 이 터 를 수정 하면 원본 요청 에서 ngx. ctx. * 의 데 이 터 를 파괴 합 니 다. 새 요청 은 빈 ngx. ctx table 입 니 다. 예 를 들 어 ngx. exec, rewrite 가 last / break 와 함께 사용 할 때 입 니 다.
ngx. ctx 내부 재 설정 에 사용 되 는 예 는 다음 과 같 습 니 다.

location /subq {
    header_filter_by_lua_block {
        --  ngx.ctx.test   ，  not test   a
        local a = ngx.ctx.test or 'not test'
        --       
        ngx.header["test"] =  a .. ' world!'
    }
    content_by_lua_block {
        ngx.say(ngx.ctx.test)
    }
}
location / {
    header_filter_by_lua_block {
        ngx.header["test"] =  ' world!'
    }
    content_by_lua_block {
        ngx.ctx.test = "nginx"
        --       
        ngx.exec("/subq")
    }
}

실행 결 과 는 다음 과 같 습 니 다.

# curl   -i 'http://testnginx.com/'
HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Mon, 18 Jun 2018 05:36:38 GMT
Content-Type: application/octet-stream
Transfer-Encoding: chunked
Connection: keep-alive
test: not test world!

nil

실행 결 과 를 통 해 알 수 있 듯 이 ngx. ctx. test 는 내부 에서 방향 을 바 꾼 후에 비어 있 습 니 다.메모: ngx. ctx 를 조회 하면 메타 방법 호출 이 발생 합 니 다. 이것 은 일정한 서버 자원 을 소모 할 수 있 으 므 로 데이터 가 함수 로 생 성 될 수 있다 면 가능 한 한 ngx. ctx 를 사용 하지 마 십시오.ngx. ctx 가 성능 에 미 치 는 영향 을 더 알 고 싶다 면 화염 도 를 통 해 성능 을 분석 할 수 있 습 니 다 (제1 6 장 참조).