Redis Stream PubSub
3줄 요약
Redis Stream PubSub 챕터는 Redis Pub/Sub을 휘발성 실시간 알림으로, Redis Stream을 ID, consumer group, ack, pending entry가 있는 가벼운 stream으로 구분한다.- 핵심은 메시지가 사라져도 되는지, 다시 읽어야 하는지, pending을 누가 claim할지, Redis 메모리와 trim 정책이 replay 요구를 깨지 않는지 판단하는 것이다.
- Java/Spring 백엔드 개발자는 Redis를 빠른 내부 이벤트 도구로 쓸 때도 처리 이력, ack 위치, 중복 처리, Kafka 전환 기준을 설명할 수 있어야 한다.
핵심 정리
PubSub과 Stream 차이: Pub/Sub은 subscriber가 접속 중일 때만 전달되는 fan-out에 가깝고, Stream은 메시지를 저장하고 ID 기준으로 읽을 수 있다.Redis Stream Consumer Group: consumer group은 Stream entry를 consumer들이 나눠 처리하게 하지만 consumer 이름, group offset, pending entry 관리가 필요하다.Pending Entry와 Ack: pending entry는 읽었지만 XACK되지 않은 항목이다. business 처리 완료 전 ack하면 누락, ack 전에 죽으면 중복 가능성이 생긴다.Redis 기반 이벤트 처리 한계: Redis Stream은 가볍지만 메모리 기반 운영, trim, single shard 한계, 장기 replay 요구에서 Kafka보다 빨리 한계가 온다.Kafka와 Redis Stream 선택 기준: 짧은 내부 비동기 처리와 단순 replay는 Redis Stream, 장기 보관·대규모 fan-out·partition 확장은 Kafka를 먼저 검토한다.- 이 챕터는 Web-Database의 DB transaction/query가 아니라 Redis를 event 전달 경로로 쓸 때의 유실, pending, replay, 운영 한계를 다룬다.
헷갈리는 지점
- Pub/Sub과 Stream을 둘 다 “Redis 메시징”으로만 묶으면 유실 조건을 놓친다.
- Pub/Sub은 subscriber가 없거나 끊겨 있으면 메시지를 받지 못한다.
- Stream은 저장되지만 trim이나 메모리 정책 때문에 무한 replay 저장소가 아니다.
- Stream에 consumer group이 있다고 Kafka와 같은 수준의 event log가 되는 것은 아니다.
- Redis Stream은 partition topic, 긴 retention, broker ecosystem, 대규모 replay 운영에서 Kafka와 다르다.
- 그래서 “가볍게 시작”과 “오래 버틸 event backbone”을 구분해야 한다.
XACK는 business 성공 선언이지 Redis 명령 성공만의 문제가 아니다.
- DB 저장 전에 ack하면 누락될 수 있고, DB 저장 후 ack 전에 죽으면 중복될 수 있다.
- 따라서 Redis Stream consumer도 처리 이력과 멱등성이 필요하다.
확인 질문
- 이 챕터의 핵심 판단 기준은 무엇인가?
- 메시지가 유실돼도 되는지, Stream ID와 pending entry로 재처리할 수 있는지, Redis 보관/trim 정책이 필요한 replay 범위를 남기는지다.
- Web-Database와의 경계는 무엇인가?
- Web-Database는 DB 내부 정합성과 query를 다루고, 이 챕터는 Redis를 통과하는 event 전달과 ack 이후의 중복·누락을 다룬다.
- 개인 프로젝트에서 최소로 챙길 것은 무엇인가?
- Pub/Sub과 Stream 선택 근거,
XADD/XREADGROUP/XACK/XPENDING 예시, pending claim 절차, 같은 메시지 재처리 테스트다.