📨 Kafka vs RabbitMQ vs Redis Pub/Sub

1️⃣ 메시징 시스템의 공통 목표

• 서비스 간 결합도 낮추기
• 트래픽 폭주를 흡수
• 비동기 처리와 장애 복원력 확보
• 신뢰성 있는 전달

하지만 이 공통 목표를 어떤 방식으로 구현하느냐가 Kafka, RabbitMQ, Redis Pub/Sub의 근본적 차이.

 

2️⃣ Kafka — “로그 스트림 기반 이벤트 플랫폼”

🧠 개념

Kafka는 단순한 메시지 큐가 아니라 분산 로그 저장소.

모든 메시지는 디스크에 Append-Only로 기록되고,

Consumer Group이 각자 오프셋을 관리하며 읽음.

 

✅ 강점

- 초고속 처리량

- 리플레이 가능: retention 기간 동안 재소비 가능

- 확장성: Broker + Partition 기반 선형 확장

- Exactly-once 처리 지원 (Kafka Streams / Transactional API)

 

⚠️ 한계

- 브로커 운영이 복잡함

- 메시지 실시간성보단 대량 처리에 최적화

- 순서 보장은 파티션 내에서만 가능

 

🧩 사용 예시

- 데이터 파이프라인 (로그 수집, CDC, 검색 인덱스 갱신)

- 도메인 이벤트 전달

- 스트림 프로세싱 

 

3️⃣ RabbitMQ — “신뢰성 있는 큐 중심 메시지 브로커”

🧠 개념

RabbitMQ는 AMQP 프로토콜 기반의 메시지 브로커로,

Exchange -> Queue -> Consumer 라우팅 모델을 사용.

즉, 메시지가 들어오면 Exchange에서 라우팅 규칙에 따라

하나 이상의 Queue로 전달.

 

✅ 강점

- 메시징 패턴이 다양함

- ACK 기반 전달 보장

- 메시지 우선순위, DLQ, TTL 등 비즈니스 큐에 유리한 기능

- 간단한 1:1 / 1:N 워크큐 모델

 

⚠️ 한계

- 처리량은 Kafka보다 낮음

- 메시지 순서 보장이 약함(멀티큐 병렬 처리 시)

- 큰 메시지나 초대량 트래픽에는 부적합

 

🧩 사용 예시

- 주문 처리/배송 요청 등 업무 단위 큐

- 이메일/푸쉬 알림/백오피스 작업

 

4️⃣ Redis Pub/Sub — “가볍고 빠른 실시간 알림”

🧠 개념

Redis의 Pub/Sub은 메모리 기반 실시간 브로드캐스트 기능.

Publisher가 채널에 메시지를 발행하면

그 채널을 구독한 모든 Subscriber에게 즉시 전송됨.

 

✅ 강점

- 매우 낮은 지연

- 운영이 간단함

- 채팅방, 알림, 게임 서버 등 초실시간 이벤트에 적합

 

⚠️ 한계

- 메시지 유실 가능

- 지속성 없음 (메시지 저장 안함)

- 재시도, ACK, DLQ 기능 없음

- Subscriber가 순간적으로 끊기면 메시지 놓침

 

🧩 사용 예시

- 실시간 알림/피드/채팅

- 간단한 내부 이벤트 브로커

 

5️⃣ 판단 포인트

판단 기준	Kafka	RabbitMQ	Redis Pub/Sub
데이터 유실 절대 금지	✅	✅	❌
실시간 알림 성능 최우선	⚠️	✅	✅ ✅
대규모 확장 필요	✅ ✅	⚠️	❌
메시지 순서 중요	파티션 단위	큐 단위	❌
비즈니스 로직 큐잉	⚠️	✅ ✅	❌
운영 단순성	❌	⚠️	✅ ✅