공간 서버 경계를 넘는 캐릭터의 소유권을 중복 처리와 늦은 입력 없이 이전하려면 어떤 전환점을 두어야 하나요?

공간 서버 경계를 넘는 캐릭터를 새 서버에 복사했다고 해서 새 서버가 유일한 권위자가 된 것은 아닙니다. 기존 서버와 새 서버가 동시에 이동·전투·보상을 처리하면 이벤트가 중복되고 순서가 뒤섞이므로, 상태 복사와 소유권 확정을 분리한 명시적 전환점을 둬야 합니다. 이전 작업 ID와 단조 증가하는 owner epoch를 발급하고, 모든 쓰기가 현재 epoch를 통과할 때만 적용되게 하는 방식이 소유권 펜싱(ownership fencing)입니다.

전환 단계

예를 들어 새 서버가 이전 서버의 최신 상태와 다음 epoch g+1을 받아 준비 상태가 되면, 기존 서버는 신규 입력 수신을 막고 이미 처리 중인 입력을 drain합니다. 마지막 변경분과 처리된 입력 번호를 새 서버에 전달하고, 새 서버가 이를 적용했다는 확인을 받은 뒤 전환점을 내구적으로 기록합니다. 그 이후 라우터는 캐릭터 ID를 epoch g+1 서버로 보냅니다. 전환 중 입력을 완전히 잠깐 보류할 수 있으면 순서가 단순하고, 무중단이 필요하면 입력을 handoff ID·순서 번호와 함께 버퍼링해 마지막 delta 뒤 한 번만 적용합니다. 두 서버 모두 처리한 뒤 결과를 나중에 합치는 방식은 전투·보상처럼 비가역 효과에서 안전하지 않습니다. 모든 상태 변경과 이벤트 소비자는 자신이 가진 epoch를 현재 소유 epoch와 비교해야 합니다.

이전 서버의 늦은 입력이나 지연된 handoff 메시지가 도착해도 조건부 갱신이 거절되어야 하며, 서버가 단지 “나는 이전 owner가 아니다”라고 판단하는 것에만 의존하면 검사 뒤 쓰기까지의 TOCTOU 경쟁이 남습니다. 주변 서버의 복제본은 관찰·예측용이지 권위 있는 쓰기 경로가 아닙니다. 외부 보상·결제 이벤트도 안정적인 account·character ID와 권리 키를 사용하고, 라우터가 현재 owner epoch를 조회해 올바른 서버로 전달하거나 handoff 중 버퍼링해야 합니다.

실패와 경계 진동

이전 상태는 단계별로 내구화하고, 준비·입력 차단·drain·최종 delta 적용·권위 전환·완료 상태를 재시작 뒤에도 읽을 수 있어야 합니다. 새 서버가 확인 전에 죽으면 기존 서버가 epoch g를 유지할지, 복구 조정자가 재개할지 정합니다. 확인 뒤 라우터가 낡은 캐시를 사용하면 이전 서버로 입력을 보내므로 owner epoch를 라우팅 응답과 함께 캐시하고, 불일치하면 재조회합니다. 경계에서 캐릭터가 왕복하면 매 틱 handoff가 반복될 수 있으므로 경계 안쪽에 완충 구간을 두는 핸드오프 히스테리시스(handoff hysteresis)를 사용할 수 있지만, 이것은 권위 중복을 허용하는 방법이 아닙니다. 테스트는 경계 왕복, 이전 중 입력·공격·접속 종료, 양쪽 서버 재시작, 지연된 delta·handoff, 새 서버 확인 전 장애, 완료 후 오래된 쓰기를 포함합니다.

성능보다 먼저 어느 순간에도 유효한 owner가 하나뿐이고, 각 입력·보상 이벤트가 중복·역순 없이 처리되는지 확인하겠습니다. handoff는 상태 복사가 아니라 펜싱된 권위 전환 프로토콜(fenced authority-transfer protocol)입니다. 전환점은 메모리 상태가 아니라 외부에서 관찰 가능한 순서로 정의해야 합니다. 새 서버가 준비됐다는 응답만으로 라우팅을 바꾸지 않고 마지막 입력 번호·상태 버전·적용 보상 이벤트를 포함한 커밋 레코드를 기록한 뒤 라우터가 확인하게 하겠습니다. 이전 서버가 drain 중 죽으면 복구 조정자가 처리 범위를 읽고 확인되지 않은 입력만 새 서버에 전달하되 입력 ID로 중복을 막습니다. 경계 전투처럼 두 캐릭터가 다른 서버에 있으면 한 owner만 정하는 것으로 부족할 수 있습니다. 교차 경계 충돌의 임시 판정 영역이나 양쪽 상태의 읽기 스냅샷을 두고, 피해·보상 확정 효과는 한 권위 경로에서만 생성하겠습니다.

라우팅 캐시가 오래되면 epoch 불일치 응답으로 재조회하게 하고 handoff 반복률과 보류 입력 시간을 관리하겠습니다.