여러 워커가 DB 작업 테이블을 읽을 때 SKIP LOCKED로 나누면 중복 실행과 기아도 해결되나요?

SKIP LOCKED는 다른 트랜잭션이 잠근 행을 기다리지 않고 건너뛰게 합니다. 워커 간 즉시 경합을 줄이지만 정확히 한 번 실행이나 공정한 순서를 보장하는 기능은 아닙니다.

동작 원리와 전제

짧은 트랜잭션에서 대기 작업을 잠그고 running 상태·소유자·lease를 기록한 뒤 커밋하고 실제 작업을 실행할 수 있습니다. 외부 호출 내내 행 잠금을 잡으면 연결·락이 오래 점유됩니다. 반대로 상태 기록 없이 잠금만 풀면 다른 워커가 같은 작업을 가져갑니다.

선택과 실패 처리

워커가 죽으면 만료된 작업을 재획득할 정책이 필요합니다. lease 만료 뒤 옛 워커가 살아 있을 수 있으므로 외부 효과의 멱등 키와 완료 갱신의 세대 조건을 둡니다. 계속 잠기는 행은 뒤로 밀릴 수 있어 가장 오래된 작업과 재시도 횟수를 관찰합니다.

구체적인 사례와 검증

워커 A가 작업 1을 오래 잠그고 B가 작업 2·3을 처리하면 큐의 등록 순서와 완료 순서가 달라집니다. 결제 상태처럼 앞 작업의 효과가 후속 작업의 전제라면 이 구조를 그대로 적용할 수 없습니다. 독립 작업 큐에 사용하거나 계정별 선행 상태를 따로 검사해야 합니다. 획득 transaction이 짧아진 뒤에는 실행권을 row lock 대신 내구 상태로 표현해야 합니다. 완료 UPDATE에 작업 ID·owner·generation을 함께 넣어 새 owner의 상태를 옛 워커가 덮지 못하게 합니다. 실패 작업의 backoff와 최대 대기 나이를 기록하면 항상 뒤로 밀리는 행을 찾을 수 있습니다. 처리 기록을 먼저 완료로 표시한 뒤 외부 작업을 시작하지 않습니다.

처리 순서를 ORDER BY로 표현해도 잠긴 행을 건너뛴 결과는 엄격한 FIFO가 아닙니다. 빈 조회가 전체 큐가 비었다는 뜻인지 잠긴 작업만 남았다는 뜻인지 구분합니다. 획득·외부 성공·완료 기록 전후의 중단을 시험해 중복·유실·유령 작업을 검증하겠습니다.