Kafka Redis RabbitMQ

Kafka vs Redis vs RabbitMQ 비교표

주요 역할	분산 메시지 스트리밍 플랫폼	메모리 기반 메시지 브로커 & 캐시	전통적인 메시지 브로커
메시지 처리 방식	Pub/Sub (로그 저장 및 스트리밍)	Pub/Sub + 메시지 큐	메시지 큐 (AMQP 프로토콜)
메시지 순서 보장	✅ Partition 내에서 순서 보장	❌ 기본적으로 순서 보장 안 됨	✅ 기본적으로 순서 보장
메시지 저장 여부	✅ 영구 저장 (디스크 저장 가능)	❌ 기본적으로 메모리 저장 (설정 필요)	✅ 영구 저장 가능 (설정 필요)
메시지 소비 방식	여러 Consumer가 같은 메시지 읽기 가능	Queue 기반 (단일 Consumer가 메시지 소비)	Queue 기반 (단일 Consumer가 메시지 소비)
확장성	✅ 매우 뛰어남 (수천 개의 Consumer 가능)	❌ 단일 노드에 종속 (클러스터링 어려움)	⚠️ 중간 정도 (Cluster 가능하지만 Kafka만큼 확장성 높지 않음)
성능	고성능 (초당 수백만 건 가능)	매우 빠름 (메모리 기반, ms 단위 처리)	빠르지만 Kafka보다는 성능 낮음
장애 발생 시 메시지 처리	✅ Consumer가 메시지 재처리 가능	❌ 기본적으로 메시지 유실 가능 (Persistence 필요)	✅ 메시지 Ack/Nack으로 복구 가능
주요 사용 사례	로그 처리, 이벤트 스트리밍, 빅데이터 분석	빠른 캐싱, Pub/Sub, 단순한 메시지 처리	비동기 작업 처리 (Celery, 금융 시스템 등)

Kafka 사용 추천 (대규모 데이터 스트리밍)

• 실시간 이벤트 스트리밍, 로그 처리, 데이터 파이프라인 구축
• 대량의 메시지를 순서대로 유지하며 저장하고 싶을 때
• 여러 Consumer가 같은 메시지를 구독해야 할 때 (Pub/Sub)
• **데이터 영속성(Persistence)**이 중요할 때

💡 사용 예제: 실시간 로그 분석, 주문 처리 시스템, IoT 데이터 스트리밍

---

✅ Redis 사용 추천 (빠른 메시지 처리 & 캐싱)

• 짧은 시간 유지되는 메시지를 빠르게 전달해야 할 때
• 고성능, 저지연 메시징이 필요할 때 (ms 단위 응답)
• 캐싱, 세션 관리, Pub/Sub, 실시간 랭킹 처리
• 메시지 유실이 크게 중요하지 않을 때

💡 사용 예제: 채팅 시스템, 실시간 랭킹, 캐싱, 빠른 작업 큐

---

✅ RabbitMQ 사용 추천 (전통적인 메시지 큐 & 안정적인 메시지 전달)

• 신뢰성이 중요한 메시지 처리 (금융 시스템, 주문 처리 등)
• 메시지를 한 번만 전달하고 정확한 순서로 처리해야 할 때
• 메시지 유실을 방지하고, 작업 실패 시 재시도(Ack/Nack)가 필요할 때

💡 사용 예제: Celery 비동기 작업 처리, 금융 거래 시스템, 이메일 큐

---

📌 결론: Kafka, Redis, RabbitMQ의 차이점

• Kafka → 대규모 데이터 스트리밍 & 이벤트 처리 (Pub/Sub)
• Redis → 빠른 캐싱 & 실시간 메시지 처리 (단순 Pub/Sub & Queue)
• RabbitMQ → 신뢰성이 필요한 메시지 큐 (AMQP 기반, 정확한 메시지 전달)