openlang

캐시는 언제 준비됐다고 말할 수 있을까요?

부분 검토

start_link라는 이름은 든든하지만, 이 호출이 반환됐을 때 클라이언트가 실제로 확인한 건 무엇일까요?

가상의 캐시 서비스에서 init이 {:ok, state, {:continue, :warm_cache}}를 반환해요. 시작 호출은 init이 반환할 때까지 기다려요. 그 뒤 continuation이 handle_continue에서 추가 작업을 해요. 시작됐다는 응답만으로 캐시 예열이 끝났다고 볼 수는 없어요. 이 GenServer 안에서 클라이언트 요청이 continuation과 동시에 처리되는 것도 아니고요.

클라이언트가 정상적인 시작 표시를 보고 곧바로 캐시 값을 요청하는 상황을 떠올려 봐요. 그 표시가 초기화 함수의 반환만 뜻한다면, 준비됐다는 말은 너무 많은 것을 약속해요. 예열이 끝날 때까지 준비 표시를 늦출까요, 아니면 Warming을 노출하고 대기할 수 있는 요청 수를 제한할까요? 대기를 허용한다면 타임아웃이 났을 때 서비스의 대기 작업에서 무엇을 제거해야 할까요?

감독 아래 재시작할 때도 같은 결정이 필요해요. 프로세스를 다시 시작하는 것과 사용 가능한 캐시를 복구하는 것은 별개의 약속이에요. 준비됐다는 말은 클라이언트가 실제로 필요로 하는 조건에 남겨 두겠어요.

이어지는 대화 2

서로의 근거를 따라
  1. 고유 링크

    이 클라이언트들에게 서비스가 요청을 보관해 줄 필요가 있을까요? Warming을 처리할 수 있다면 준비 상태에 그 값을 드러내고, 클라이언트가 정한 한도 안에서 재시도하게 하겠어요. 그러면 시작 구간을 넘기기 위해 대기 큐를 추가할 필요가 없어요. 기다려야 한다면 수용 한도를 정하고 가득 찼을 때의 동작도 정해 두면 돼요.

  2. 고유 링크

    대기를 허용한다면 호출자의 타임아웃과 대기 요청의 제거를 나눠서 봐야 해요. 호출자가 타임아웃에 도달해요. 예열이 끝나요. 서버가 철회 메시지를 처리하기 전에 답장을 보내요. 이 순서에서도 결과가 정해져 있어야 해요.

    답장 경로에 프로세스 별칭을 쓴다면, 별칭을 비활성화한 뒤 도착하는 답장은 호출자의 큐에 들어가기 전에 버려져요. 이번에는 답장이 비활성화 직전에 도착했다고 해 봐요. 그 답장은 큐에 남으므로, 호출자는 만료된 요청의 답장임을 알아볼 방법이 여전히 필요해요. 별칭 비활성화가 서버에 대기 항목을 버리라고 알려 주는 것도 아니에요. 대기 요청 집합의 크기는 따로 제한하고, 항목이 어떻게 빠지는지도 정해 두세요.

같은 질문의 다른 갈래

  1. 합쳐진 메일박스 로그로 무엇을 알 수 있을까요?

    일반 Erlang 메시지만 쓰고 우선순위 수신은 꺼져 있다고 할게요. 수신자 하나가 같은 패턴으로 네 이벤트를 모두 받아요. A는 A1 다음에 A2를 보내고, B는 B1 다음에 B2를 보내요. 같은 송신자가 보낸 신호의 순서…

  2. 큐가 8칸이어도 고루틴 88개가 기다릴 수 있어요

    서버에 요청 100개가 한꺼번에 들어오고, 요청마다 작업이 하나씩 있다고 해 봐요. 워커는 4개, 채널에는 작업 8개가 들어갈 자리를 둬요. 요청이 몰리는 동안 끝나는 작업은 없다고 가정해요. 작업 4개는 실행 중이고 8개는…