2017-01-12 5 views
2

하늘색 API 관리자 정책에 특정 값을 캐싱하고 경우에 따라 항목을 제거하여 캐시를 정리하고 API에서 값을 검색합니다.Azure Api 캐시 캐시 항목을 제거하지 않는 관리자 캐시 제거 값 정책

캐시 제거 값 정책을 사용하여 값을 제거한 후에도 내 다음 API 호출은 여전히 ​​캐시의 값을 찾습니다. 다음은 샘플 코드입니다 :

<cache-store-value key="Key123" value="123" duration="300" /> 
    <cache-lookup-value key="Key123" variable-name="CacheVariable" /> 
    <cache-remove-value key="Key123" /> 
    <cache-lookup-value key="Key123" default-value="empty" variable-name="CacheVariable2" /> 
    <return-response> 
     <set-status code="504" reason="" /> 
     <set-body>@(context.Variables.GetValueOrDefault<string>("CacheVariable2"))</set-body> 
    </return-response> 

이 코드는 기본적으로 반환 비어 있거나 키 Key123와 캐시 항목을 제거하거나하지 후에 발견 된 경우에 따라 본문에 "123". 이 값은 항상 캐시 된 항목 "123"의 값을 반환합니다.

이 문제가 발생했거나 캐시를 정리하는 방법을 찾은 사람이 있습니까?

Ret Retry를 계속 체크인하면 항목이 2 초 후, 때로는 1 분 후 청소되는 경우가 있습니다. 삭제 호출은 백그라운드에서 비동기식 또는 대기열에있는 호출이라고 생각하여 지속적으로 확인하지 않고도 정리 된 것인지 여부를 확실히 알 수 없습니다.

UPDATE : 지금은 실제 솔루션으로

대신 삭제, 나는 실제로 일초 기간과 더러운 값으로 캐시 항목을 업데이트합니다.

+0

. 대개의 경우 redis 캐시를 분산 호출하기 때문에 이러한 종류의 작업을 차단하고 싶지는 않습니다. 흥미롭게도 나는 업데이트 캐시가 같은 일을 할 것이라고 기대할 것이므로 귀하의 대안으로 다른 행동을하는 이유를 확신 할 수 없습니다. –

+0

계속 진행하기 전에 cache-remove-value가 완료 될 때까지 정책 처리가 대기하지 않지만 cache-store는 수행합니다. 따라서 해결 방법이 작동하지만 더 나은 방법이 있어야합니다. –

답변

0

캐시 제거 요청이 요청 처리 파이프 라인과 관련하여 비동기 적으로 발생합니다. 즉, APIM은 요청을 계속하기 전에 캐시 항목이 제거 될 때까지 대기하지 않으므로 제거 요청 후 즉시 검색 할 수 있습니다 아직 보내지 않았다.

은 시나리오에 따라 업데이트 : 왜 당신은 다음과 같은 것을 시도하지 않는 : 나는 비동기 있는지 확인합니다,하지만 나를 놀라게하지 것이다

<policies> 
<inbound> 
    <base /> 
</inbound> 
<backend> 
    <retry condition="@(context.Response.StatusCode == 200)" count="10" interval="1"> 
     <choose> 
      <when condition="@(context.Variables.GetValueOrDefault("calledOnce", false))"> 
       <send-request mode="new" response-variable-name="response"> 
        <set-url>https://EXTERNAL-SERVICE-URL</set-url> 
        <set-method>GET</set-method> 
       </send-request> 
       <cache-store-value key="externalResponse" value="EXPRESSION-TO-EXTRACT-DATA" duration="300" /> 
       <!--... or even store whole response ...--> 
       <cache-store-value key="externalResponse" value="@((IResponse)context.Variables["response"])" duration="300" /> 
      </when> 
      <otherwise> 
       <cache-lookup-value key="externalResponse" variable-name="externalResponse" /> 

       <choose> 
        <when condition="@(context.Variables.ContainsKey("externalResponse"))"> 
         <!-- Do something with cached data --> 
        </when> 
        <otherwise> 
         <!-- Call extenal service and store in cache again --> 
        </otherwise> 
       </choose> 

       <set-variable name="calledOnce" value="@(true)" /> 
      </otherwise> 
     </choose> 
     <forward-request /> 
    </retry> 
</backend> 
<outbound> 
    <base /> 
</outbound> 

+0

그 문제는 APIM이 캐시 제거 동작을 비동기 동작으로 재 포장하지 않는다는 것입니다. 캐시 제거와 관련하여 "대기"정책을 사용하면 비동기/대기 작업 만 "대기"절에 넣을 수 있다는 예외가 생깁니다. –

+0

대기 정책은 정책을 병렬로 실행하고 일부 또는 전체 완료시 계속 진행하는 방법입니다. 대기 상태가 아닌 정책은 요청 처리를 계속 차단합니다. 반면에 캐시 제거는 요청 처리를 차단하지 않으며 저장 프로 시저 값을 캐시하지도 않습니다. 당신의 시나리오는 무엇입니까? 이 요청 처리 중에 생성 된 값으로 캐시를 업데이트 했으므로 값을 이미 사용할 수 있으며 가져 오기 위해 캐시로 이동할 필요가 없습니다. –

+0

내 케이스 : 나는 백엔드에서 요청에 사용될 외부 서비스에서 데이터를 검색한다. 가치가 유효한지 나는 모른다. 호출이 성공하면 다음 5 분 내에 여러 호출에 필요하므로 값을 캐시합니다. 매번 외부 서비스를 호출하면 2 초의 오버 헤드가 추가되어 피할 수 있습니다. 백엔드 엔진이 유효하지 않은 응답을 반환하는 경우이 5 분 동안 캐시를 지우고 "다시 시도"를 호출 응용 프로그램으로 반환하여 다음 호출이 수행되고 업데이트 된 값을 검색하기 위해 외부 서비스를 다시 호출합니다. –