📌 개요
현재 대기열 시스템은 모든 사용자가 큐를 통과한 후 AdmissionScheduler (5 초 주기)가 batch 로 admit 처리함
이로 인해 트래픽이 적을 때도 사용자가 최소 5 초 대기해야 하므로 사용성이 낮다.
동시 입장 가능한 인원수 한계를 도입하여:
- 한계 이하 → 즉시 admit
- 한계 초과 → 큐 + 배치 admit (현재 동작 유지)
🎯 완료 기준
QueueProperties 에 maxConcurrentAdmitted (동시 입장 가능 인원) 설정 추가
- 활성 ADMITTED 토큰을 별도 Sorted Set (
queue:program:{programId}:admitted) 으로 관리
- enqueue 시 현재 ADMITTED 수가 한계 미만이면 즉시 admit 처리되고 폴링 시 ADMITTED 응답 반환
- enqueue 시 현재 ADMITTED 수가 한계 이상이면 큐에 진입하고 폴링 시 WAITING + position 반환
- AdmissionScheduler 가 한계 미만일 때만 batch admit 수행
- entryToken 만료 시 admitted Sorted Set 에서 자동 정리
- 부하테스트로 도입 전후 비교 측정 (적은 사용자 / 많은 사용자)
🧩 작업 범위
🏗️ 설계 요약
Sorted Set 구조
key: queue:program:{programId}:admitted
member: tokenId
score: entryToken 만료 시각 (epoch milli)
ZADD: admit 시
ZCARD: 현재 active 수 조회 (O(1))
ZREMRANGEBYSCORE: 만료 토큰 정리 (score < now)
핵심 흐름
[enqueue]
ProgramMeta 검증 (활성 시간 / status)
만료 토큰 정리 (ZREMRANGEBYSCORE)
현재 admitted 수 조회 (ZCARD)
한계 미만:
토큰 생성 + ADMITTED + entryToken 발급
admitted Sorted Set 에 ZADD
한계 이상:
토큰 생성 + WAITING
큐 Sorted Set 에 ZADD
[AdmissionScheduler 5 초마다]
활성 프로그램 조회
각 프로그램:
ZCARD 로 현재 admitted 수 확인
한계 미만이면 batch admit (한계까지)
한계 도달 시 admit 안 함
[만료 정리]
enqueue 시점에 ZREMRANGEBYSCORE 본문
또는 별도 Scheduler 본문
🔗 참고 자료
- 참고 자료 혹은 이미지 삽입 등이 필요한 경우, 이곳에 작성해주세요.
📌 개요
현재 대기열 시스템은 모든 사용자가 큐를 통과한 후
AdmissionScheduler(5 초 주기)가 batch 로 admit 처리함이로 인해 트래픽이 적을 때도 사용자가 최소 5 초 대기해야 하므로 사용성이 낮다.
동시 입장 가능한 인원수 한계를 도입하여:
🎯 완료 기준
QueueProperties에maxConcurrentAdmitted(동시 입장 가능 인원) 설정 추가queue:program:{programId}:admitted) 으로 관리🧩 작업 범위
QueueProperties에maxConcurrentAdmitted필드 추가queue.max-concurrent-admitted설정 추가queue:program:{programId}:admitted, score = entryToken 만료 시각) 도입RedisQueueTokenRepository.countActiveAdmitted(programId)추가 (ZCARD 본문)QueueTokenService.issueToken분기 (즉시 admit / 큐)AdmissionScheduler한계 검증 추가🏗️ 설계 요약
Sorted Set 구조
key: queue:program:{programId}:admitted
member: tokenId
score: entryToken 만료 시각 (epoch milli)
ZADD: admit 시
ZCARD: 현재 active 수 조회 (O(1))
ZREMRANGEBYSCORE: 만료 토큰 정리 (score < now)
핵심 흐름
🔗 참고 자료