왜 필요한가
요청을 처리할 실행 환경과 프로세스 수명을 직접 관리해야 합니다. 요청별 처리기만으로 원하는 운영 방식을 표현하기 어려운 상황입니다.
어떻게 해결하는가
글 읽기와 A17 저장은 대기 중인 프로세스로 들어갑니다. 저장은 외부 저장소에 기록합니다. 반복 저장도 예제의 독자·글 키에 따라 기록 하나만 유지합니다. 다음 저장 실패는 저장소를 바꾸지 않고 실패를 반환합니다. 처리기 재시작은 프로세스만 바꾸고 기록을 유지합니다. 초기화·새로고침은 가상 저장소를 포함한 페이지 메모리 전체를 지웁니다.
개념 시뮬레이션
상시 서버
공개 글을 읽고 A17을 저장하세요. 반복 요청은 reader-01 / A17을 공유합니다.
01 · 대기 프로세스 · 재시작 경계
GET
브라우저 → 대기 프로세스 → 글 HTML
POST A17
브라우저 → 대기 프로세스 → 외부 저장소 → 확인 응답.
실행 세대: 1 · 이 세대의 호출: 0
대기
저장소도 페이지 메모리의 모형입니다. 재시작은 유지하고 초기화·새로고침은 지웁니다. 중복 방지는 직접 작성한 앱 로직입니다.
본문 안의 가상 데모입니다. 초기화·새로고침으로 처음 상태로 돌아갑니다.
무엇이라 부르는가
상시 서버는 프로세스가 계속 요청을 기다리도록 운영하는 방식입니다. 재시작할 수 있으므로 이름이 무중단 가용성을 보장하지는 않습니다.
영속 데이터는 외부에 두고 감시·용량·복구를 맡을 담당자를 정합니다.
이 선택에 관한 이야기
세 언어가 댓글을 공유합니다. 작성하려면 GitHub 로그인이 필요합니다.