Redis Pub/Sub과 Stream

Redis는 단순 저장소뿐 아니라 Pub/Sub과 Stream으로 메시징 기능도 제공합니다. 다만 메시지 내구성, 재처리, 대규모 운영 요구가 크면 Kafka 같은 전용 브로커와 비교해야 합니다.

용어

용어	의미
Pub/Sub	publisher가 channel에 메시지를 보내면 subscriber가 즉시 받는 방식
Channel	Pub/Sub 메시지를 주고받는 이름
Keyspace Notification	key 변경 이벤트를 Pub/Sub으로 알려주는 기능
Stream	Redis의 append-only 메시지 로그 자료구조
Consumer Group	Stream 메시지를 여러 consumer가 나누어 읽는 그룹
PEL	Pending Entries List, 소비됐지만 ACK되지 않은 메시지 목록

질문

Pub/Sub과 Stream은 무엇이 다른가?

구분	Pub/Sub	Stream
저장	구독 중인 client에게만 전달	메시지가 stream에 저장됨
재처리	어려움	ID 기준 재조회 가능
Consumer Group	없음	지원
사용처	실시간 알림, cache invalidation	작업 처리, 소규모 이벤트 로그

Pub/Sub

SUBSCRIBE notification:user-1
PUBLISH notification:user-1 "new-message"

장점	단점
구조가 단순하고 빠름	subscriber가 없으면 메시지 손실
실시간 fan-out에 적합	재처리와 내구성 부족

Pub/Sub 사용 사례

사용처	설명
서버 간 cache invalidation	특정 key 삭제 알림
실시간 알림	접속 중인 사용자에게 즉시 전달
설정 변경 전파	여러 인스턴스 local cache 갱신

Pub/Sub 한계

Pub/Sub은 "지금 접속한 subscriber에게 즉시 전달"하는 모델입니다. 메시지를 저장해두고 나중에 읽는 구조가 아닙니다.

주의: 결제, 주문, 재고처럼 유실되면 안 되는 이벤트는 Pub/Sub 단독으로 처리하지 않는다.

Keyspace Notification

Keyspace Notification은 key 만료, 삭제, 변경 같은 이벤트를 Pub/Sub으로 받을 수 있게 합니다.

CONFIG SET notify-keyspace-events Ex
SUBSCRIBE __keyevent@0__:expired

장점	주의
TTL 만료 이벤트를 감지할 수 있음	설정 필요
간단한 후속 처리에 유용	이벤트 유실 가능성을 고려해야 함

Stream

Stream은 메시지를 ID와 함께 저장합니다.

XADD order-events * type ORDER_CREATED orderId 1001
XRANGE order-events - +

특징	설명
append-only	메시지가 순서대로 추가됨
ID 기반 조회	특정 ID 이후 메시지를 읽을 수 있음
Consumer Group	여러 consumer가 나누어 처리 가능
ACK	처리 완료를 Redis에 알림

Stream Consumer Group

XGROUP CREATE order-events order-service $ MKSTREAM
XREADGROUP GROUP order-service consumer-1 COUNT 10 STREAMS order-events >
XACK order-events order-service 1740000000000-0

명령	의미
`XGROUP CREATE`	consumer group 생성
`XREADGROUP`	group으로 메시지 읽기
`XACK`	처리 완료
`XPENDING`	처리 중인 메시지 확인
`XCLAIM` / `XAUTOCLAIM`	오래 pending 된 메시지 인계

Pending Entries List

PEL은 consumer가 읽었지만 아직 ACK하지 않은 메시지 목록입니다.

XPENDING order-events order-service

consumer가 죽으면 메시지가 PEL에 남을 수 있습니다. 다른 consumer가 XAUTOCLAIM으로 가져와 재처리할 수 있습니다.

Stream 메시지 재처리

상황	대응
consumer 장애	PEL 확인 후 claim
처리 실패	재시도 횟수 제한 후 DLQ stream
poison message	실패 원인과 원본 ID 저장
중복 처리	idempotency key 사용

Redis Stream vs Kafka

기준	Redis Stream	Kafka
운영 규모	소규모~중간 규모에 단순	대규모 이벤트 스트리밍
보관	Redis 메모리와 trim 정책 영향	긴 retention과 디스크 로그
재처리	가능하지만 운영 도구 제한	offset 기반 재처리 강점
consumer group	지원	강력한 생태계
사용 기준	Redis 안에서 가벼운 이벤트 처리	서비스 간 핵심 이벤트 파이프라인

베스트 프랙티스

권장 방식	이유
Pub/Sub은 유실되어도 되는 알림에 사용	저장·재처리 모델이 아님
Stream은 trim 정책 설정	무한 증가 방지
consumer는 멱등하게 구현	재처리와 중복 대비
실패 메시지는 DLQ stream으로 격리	전체 소비 중단 방지
Kafka와 역할 구분	장기 이벤트 로그는 Kafka가 더 적합한 경우가 많음

실무에서는?

사용처	추천
local cache 무효화 알림	Pub/Sub
채팅 presence 알림	Pub/Sub
간단한 비동기 작업	Stream
결제·주문 이벤트 전파	Kafka 우선 검토
Redis 내부 작업 재처리	Stream + consumer group