Please enable JavaScript.

Coggle requires JavaScript to display documents.

Message Broker로서의 Redis Pub/Sub - Coggle Diagram

- - - - 신뢰성/내결함성 강화
        메시지 영속화/재시도/Dead-Letter Queue(DLQ) 등으로 장애 시에도 메시지 보존 및 재처리 기능 제공
      - 서비스 분리/비동기화
        마이크로서비스 간 직접 호출 부담 완화,
        비동기 처리로 시스템 완충층을 제공
  - - - Redis Pub/Sub
        
        Pub/Sub 기능 탑재 이유
        
        실시간 알림/이벤트 처리 성능
        이미 메모리 기반 캐시로 운영 중인 Redis에 초저지연 Pub/Sub 기능 추가로 실시간 이벤트/알림 처리
        
        인프라 통일 및 경량화
        별도 브로커 구축 없이 기존 Redis 인프라에 메시징 기능을 확장해, 경량 메시징 아키텍처 구현 가능
        
        기본 동작 원리
        Publish-Subscribe 모델
        
        발행자(publisher)가 특정 채널에 메시지 발행
        
        구독자(Subscriber)는 관심 채널을 구독(subscribe)
        
        Redis 서버가 해당 채널 구독자 전원에게 메시지 푸시
        
        RedisMessageListenerContainer & MessageListenerAdapter: Redis에서 수신한 메시지를 MessageListenerAdapter가 처리하고, 이를 SimpMessagingTemplate을 통해 WebSocket으로 연결된 클라이언트에게 전달
        
        메시지 플로우
        (Spring WebSocket + STOMP + Redis Pub/Sub)
        
        클라이언트 구독
        
        메시지 전송
        
        Redis 발행
        
        2 more items...
        
        구독한 클라이언트가 STOMP SEND 프레임을 통해 서버의 엔드포인트 (예: /app/chat)로 메시지 전송
        
        클라이언트가 WebSocket(STOMP)으로 채팅 채널(예: /topic/chat) 구독 요청
        STOMP SUBSCRIBE 프레임 전송
      - 장점
        
        초저지연 처리: 채팅 등 실시간 서비스에 μs~ms 응답 보장
        
        간단한 도입/관리: 이미 운영 중인 Redis 확장으로 추가 인프라 도입 불필요
        
        경량 아키텍처: 메시지 보존이 불필요한 순발력 위주의 서비스에 적합
        
        비용 효율성: 별도 라이선스/운영비 없이 Redis 확장으로 활용
      - 단점
        
        메시지 비영속/신뢰성 부족: 장애 시 메시지 소실, at-most-once만 보장(실패시 재전송 불가)
        
        수평 확장 제한: Cluster 모드 구성 필요, 기본 단일 노드 의존
        
        고급 라우팅/보안 기능 부재: ACL/TLS 설정, 복잡한 라우팅 미지원
        
        모니터링/관리 도구 제한: Redis 전용 Pub/Sub 모니터링 기능은 상대적으로 단순
    - - 장점
        
        완전 관리형 서비스로 서버 운영 필요 없음
        
        메시지 영속성(최대 14일)
        
        자동 재시도
        
        Dead-Letter Queue
      - 단점
        
        지연 시간이 Redis Pub/Sub 보다 높음 (수십 밀리초 수준)
        
        Pub/Sub 모델이 아닌 Polling 구조
        
        비용 발생 (요청 단위 과금)
    - - 장점
        
        AMQP 0.9.1 표준 프로토콜 지원
        
        토픽, 라우팅 키, 헤더 교환 등 복잡한 라우팅 가능
        
        클러스터링 및 미러링으로 가용성과 내결함성 보강
      - 단점
        
        운영/튜닝 난이도 중간급
        
        대용량 메시지 처리 시 Throughput 한계
    - - 장점
        
        토픽을 파티션 단위로 수평 확장, 매우 높은 처리량 (수십만 TPS)
        
        메시지 로그 보관 기간을 길게 설정 가능
        
        스트림 프로세싱 (Stream API) 연계 우수
      - 단점
        
        운영 복잡도 높음 (Zookeeper 또는 KRaft 관리 필요)
        
        실시간성(지연 시간)은 RabbitMQ 보다 높을 수 있음(수ms 단위)