❓POLLING이란?
POLLING은 서버나 시스템이 새 데이터가 있는지 주기적으로 계속 요청해서 확인하는 방식이다.
예시
매 1초마다 LPOP coupon_queue1초마다 줄에 데이터가 있는지 확인한다.
POLLING 장점
- 구현이 단순하다 (특별한 설정 없이도 가능).
- 시스템이 스스로 제어할 수 있다 ("언제 요청할지" 스케줄링 가능).
POLLING 단점
- CPU, 네트워크 리소스를 낭비할 수 있다 (반복 요청 필요).
- 데이터가 없을 때도 무의미한 요청이 계속 발생한다.
- 실시간성이 떨어질 수 있다 (요청 주기에 따라 늦게 감지할 수 있음).
❓BLOCKING이란?
BLOCKING은 "데이터가 없으면 잠깐 멈추고 기다렸다가 생기면 바로 응답하는 방식"이다.
BLOCKING 장점
- 리소스를 아낀다 (불필요한 요청이 없음).
- 실시간성이 매우 높다 (데이터가 들어오자마자 반응).
BLOCKING 단점
- 클라이언트가 "대기 상태"가 되기 때문에, 커넥션 수가 많으면 관리가 복잡해질 수 있다.
- 잘못하면 영원히 대기하는 상황(Dead Wait)이 발생할 수 있다. (timeout 설정 주의)
POLLING vs BLOCKING 차이
| 구분 | POLLING | BLOCKING |
|---|---|---|
| 동작 방식 | 주기적으로 새 데이터 확인 | 데이터가 생길 때까지 대기 |
| 리소스 사용 | 반복 요청으로 리소스 소모 큼 | 리소스 효율적 사용 |
| 반응 속도 | 요청 주기에 따라 다름 | 데이터 생성 즉시 반응 |
❓BRPOP이란?
BRPOP(Blocking Right POP)은 Redis에서 큐(List)의 오른쪽 끝에서 아이템을 꺼내는데 없으면 일정 시간 기다렸다가 꺼내는 명령어이다.
BRPOP key timeoutkey: 데이터를 꺼낼 리스트timeout: 대기할 시간 (초 단위, 0이면 무한대기)
예시
BRPOP coupon_queue 5coupon_queue에 아이템이 없으면 5초 동안 기다렸다가 생기면 꺼낸다.
BRPOP 장점
- 큐에 데이터가 없을 때 리소스를 낭비하지 않고 효율적으로 대기할 수 있다.
- 데이터가 들어오는 즉시 바로 처리할 수 있다 (지연 최소화).
- 큐의 뒤쪽(오른쪽)에서 꺼내므로 생산-소비 모델에 적합하다. (예: producer가 데이터를 push하고 consumer가 pull)
❓BLPOP이란?
BLPOP(Blocking Left POP)은 Redis에서 큐(List)의 왼쪽 끝에서 아이템을 꺼내는데 없으면 일정 시간 기다렸다가 꺼내는 명령어이다.
BLPOP key timeout예시
BLPOP coupon_queue 5coupon_queue에 아이템이 없으면 5초 동안 기다렸다가 생기면 꺼낸다.
BLPOP 장점
- 데이터가 들어오는 즉시 반응할 수 있다 (효율적).
- 큐의 앞쪽(왼쪽)에서 꺼내므로 전형적인 Queue(First In, First Out) 구조에 잘 맞는다.
- 역시 리소스를 아끼면서 대기할 수 있다.
BRPOP vs BLPOP 차이
| 구분 | BLPOP | BRPOP |
|---|---|---|
| 꺼내는 방향 | 왼쪽 (Front) | 오른쪽 (Back) |
| 특징 | FIFO(선입선출) 방식에 적합 | 생산자-소비자 모델에 적합 |
| 예시 | 선착순 처리 | 작업 분배, 작업 결과 수집 |
둘 다 Blocking 방식이지만 꺼내는 방향만 다르다.
🔄️ 실제 예시 흐름 - 선착순 쿠폰 발급 서비스
🛠️ 시스템 구성
- 쿠폰 발급 요청이 들어오면 -> Redis Queue(coupon_queue) 에 쌓는다 (RPUSH)
- 워커 서버는 BLPOP을 통해 대기한다가 요청이 들어오면 바로 꺼내 처리한다.
흐름
- 사용자가 쿠폰 발급 요청 (ex. /api/coupon/issue)
- 서버가 쿠폰 발급 요청을 Redis coupon_queue에 RPUSH 한다.
- 워커 서버가 BLPOP coupon_queue 0 명령으로 무한 대기한다.
- 누군가 요청을 넣으면 -> 워커가 바로 깨어나서 요청을 가져온다.
- 가져온 요청에 대해
- 이미 발급받은 유저인지 체크
- 쿠폰 재고가 남아있는지 체크
- 검증을 통과하면 -> 쿠폰 발급 완료 및 DB 저장
- 발급 실패 시 -> 실패 응답 또는 에러 처리
예시
RPUSH coupon_queue "userId:100"
BLPOP coupon_queue 0RPUSH로 사용자 ID를 줄에 넣고 BLPOP으로 워커가 바로 꺼내어 발급 처리한다.
📝배운점
Blocking POP(BLPOP/BRPOP)을 활용하면 POLLING 없이도 효율적인 대기가 가능하다는 걸 알게 되었다. 특히 선착순 쿠폰 발급처럼 "빠르고 정확한 응답" 이 필요한 서비스에서
Blocking 큐 기반 처리는 정말 효과적인 패턴이라는 걸 체감했다.
POLLING 방식은 간단하지만 서버 리소스가 불필요하게 낭비될 수 있고 대규모 트래픽이 걸리는 시스템에서는 적합하지 않다는 것도 이번 경험을 통해 확실히 이해할 수 있었다. 앞으로 실시간성이 필요한 서비스에서는 Blocking 처리를 먼저 고려해야겠다.
