Redisson 분산락이란? pub/sub으로 스핀락의 Redis 부하를 없애는 원리

에그코드 기술 이야기 · 데이터베이스 Lock 시리즈 ⑤

안녕하세요, 에그코드입니다.

저희는 자체 서비스를 직접 운영하며 웹·SaaS·MVP를 만드는 개발사입니다.

4편의 스핀락은 락이 풀렸는지 계속 물어봐서 Redis에 부하를 줬습니다. 그럼 "매번 묻지 말고, 풀리면 알려달라"고 하면 어떨까요?

그걸 해주는 게 이번 5편의 Redisson입니다.

Redisson은 어떻게 다를까 — pub/sub

Redisson은 자바에서 많이 쓰는 Redis 라이브러리입니다. 스핀락과 달리 계속 폴링하지 않습니다.

락을 못 잡으면, 그 락의 해제 알림 채널을 구독하고 대기합니다. 누군가 락을 풀면 "풀렸다"는 메시지가 발행(publish)되고, 그 신호를 받은(subscribe) 서버만 깨어나 다시 시도합니다.

스핀락과 뭐가 다른가

차이는 대기하는 방식입니다. 스핀락은 "풀렸어? 아직?"을 쉼 없이 물어봅니다. 바쁜 대기죠. Redisson은 조용히 기다리다 통지가 올 때만 움직입니다.

그래서 Redis에 가는 요청이 확 줄어듭니다. 서버가 많고 대기가 길수록 이 차이는 더 커집니다. 락을 기다리는 서버가 수십 대라면, 폴링이 사라지는 것만으로 Redis가 훨씬 편해집니다.

락이 먼저 풀리는 문제 — watchdog

3·4편에서 걱정한 게 있었죠. 만료 시간(TTL)이 작업보다 짧으면, 일하는 도중에 락이 풀려버립니다.

Redisson은 watchdog으로 이걸 막습니다. 락을 쥔 서버가 살아 있고 작업이 안 끝났으면, 백그라운드에서 만료를 자동으로 연장합니다. 반대로 그 서버가 죽으면 연장이 멈춰, 락이 저절로 풀립니다.

그 외에 챙겨주는 것들

Redisson은 직접 짜기 번거로운 것들을 대신 해줍니다. 같은 스레드가 락을 또 잡아도 안전한 재진입(reentrant), 대기·만료 시간을 지정하는 tryLock, 여러 명령을 원자적으로 묶는 Lua 스크립트 처리까지요.

스핀락을 손수 짜며 신경 쓰던 것들을 라이브러리가 감춰 줍니다.

정리하며

Redisson은 pub/sub으로 부하를 줄이고, watchdog으로 만료 문제까지 다뤄 스핀락보다 안전합니다.

저희 에그코드는 자체 서비스를 운영하며, 트래픽·구조에 맞는 락 전략을 매번 골라 정합성 문제가 없도록 합니다.

함께 읽어보세요 — 동시성 제어, 결국 뭘 언제 쓸까 — 선택 기준 3가지 · 분산 락 — Redis로 한 번에 하나만 보장하기 · 낙관적 락 — 동시성 문제의 출발점 · 비관적 락 — 먼저 잠그고 시작하는 방식