그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Cache
Cache

분산 환경에서 Redis를 활용한 잠금은 어떻게 구현할 수 있나요?

실무4/5
설계5/5
인간4/5
기초2/5

면접관의 질문 의도

SET NX로 잠금을 짜는 수준에서 멈추는지, 복제 지연·failover로 잠금이 깨지는 시나리오와 RedLock의 가정·한계까지 짚는지를 가른다.

큐레이션 답변

학습 자료

SET key value NX 옵션으로 키가 없을 때만 잠금을 획득하고, 작업이 끝나면 키를 삭제해 해제한다. 단일 마스터-레플리카 환경에서는 복제 지연과 failover 시 잠금이 두 곳에 동시에 잡힐 수 있어 상호 배제가 깨진다. RedLock은 독립된 여러 노드에서 과반수 획득을 조건으로 걸어 신뢰도를 올리는 변형이고, 실제 운영에서는 TTL·재시도·멱등 처리를 한 세트로 묶어야 잠금이 망가져도 시스템이 무너지지 않는다.

좋은 답변 구조

  1. 01SET NX 기반 잠금 획득·해제의 기본 흐름을 설명한다
  2. 02TTL과 해제 시 소유자 검증 같은 안전 장치를 짚는다
  3. 03복제 지연·failover에서 잠금이 깨지는 시나리오를 설명한다
  4. 04RedLock의 동기·한계와 멱등 처리를 함께 묶어 답한다

자주 실수하는 포인트

잠금 해제 시 본인 소유 검증 없이 DEL만 호출해 남의 잠금을 풀어버린다
TTL을 걸지 않아 클라이언트가 죽으면 잠금이 영원히 남는다
잠금만 믿고 비즈니스 멱등 처리를 생략해 잠금이 깨졌을 때 그대로 중복 처리된다

실무 맥락

  • 여러 서버에서 같은 배치 잡이 동시에 트리거될 수 있어 한 번만 실행되도록 임계 구간을 잡아야 하는 환경
  • 결제·쿠폰처럼 중복 호출이 한 번 통과하면 바로 돈이 빠지는 임계 영역
  • 한정 수량 재고를 여러 워커가 동시에 차감하는 구간에서 초과 차감을 막아야 하는 상황

본인 경험에 녹이는 힌트

결제·쿠폰 같은 임계 구간에서 중복 처리를 막아본 적이 있다면 잠금 정책과 멱등 키 설계 경험으로 연결할 수 있다

작업이 길어져 TTL이 먼저 끝나는 바람에 두 프로세스가 동시에 진입한 사고를 본 적이 있다면 TTL 산정 기준 이야기로 풀 수 있다

Redis failover 직후 데이터 정합성 이슈를 겪었다면 RedLock 도입 검토와 그 한계까지 풀어낼 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1잠금 해제를 Lua 스크립트로 처리하는 이유는 무엇인가요
Q2RedLock의 한계는 어떤 상황에서 드러나나요
Q3DB 락과 Redis 락은 어떻게 선택하나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문