본문 바로가기
카테고리 없음

redis(2) - pub & sub

by ernest45 2025. 2. 16.

    • redis pub sub 기능
      • redis를 활용하여 메시지를 발행하고 구독하는 서비스
      • 특징
        • Redis Pub/Sub 시스템에서 동일한 채널을 여러 구독자가 구독하면, 해당 채널로 발행된 메시지가 모든 구독자에게 발송
        • 한번 발송된 메시지는 저장되지 않음
      • 실습예시)
        • 터미널1 : SUBSCRIBE test_channel
        • 터미널2 : PUBLISH test_channel "Hello, this is a test message"
      • 활용
        • 기본적으로 채팅과 같은 서비스의 경우 특정 서버에 서비스가 의존적이기에 다수의 서버를 운용하면서 채팅서비스(또는 알림서비스)를 운영할때에 pub/sub 구조 활용가능
    • redis streams
      • pub/sub과 다르게 stream은 메시지가 저장되어 소비자가 나중에라도 읽을 수 있음
      • kafka와 자료구조가 유사
      • 실습예시)
        • XADD test_stream * message "Hello, this is a test message"
          • XADD : Redis Stream에 데이터를 추가할 때 사용
          • test_stream: 스트림 이름
          • *: 메시지의 고유 ID를 Redis가 자동 생성
        • XREAD BLOCK 10000 STREAMS test_stream $
          • BLOCK 10000: 최대 10초(10000ms) 동안 대기
          • $: 현재 마지막 메시지 이후에 오는 새 메시지를 기다림.
        • XRANGE test_stream - +
          • XRANGE 명령어는 Redis Stream에서 메시지를 조회할 때 사용
            • : 시작 범위(처음부터)
          • +: 끝 범위(끝까지)
      • 활용
        • 이벤트 기반 시스템
        • 채팅 및 알림 시스템
  •  
  • DB서버 구성
    • Replication (복제)
      • master/slave
      • REDIS DB 기본 구성
      • 하나의 마스터 서버가 쓰기 작업을 처리하고, 여러 슬레이브 서버가 마스터의 데이터를 복제하여 읽기 작업을 처리
    • 클러스터 구성
      • 추가적인 설정과 구성 필요
      • Redis 클러스터는 데이터를 여러 노드에 분산하여 저장함으로써 고가용성과 확장성을 제공
      • 클러스터는 자동으로 데이터 샤딩을 수행하고, 노드 간의 복제를 통해 장애 복구를 지원

 

 

 

 

 

master/slave 구성

 

 

cluster 구성

 

 

 

 

1. pub/sub

 

 

 

publish 

subscribe

 

 

일반적인 웹서버는 사용자에게 데이터를 요청하고 거기에 맞는 응답으로 이루어짐

 

redis의 pub/sub은 발행과 구독의 형태로 채팅이나, 알림 시스템에 어울림

 

 

 

 

 

ex) 채팅 시스템 예시

 

 

 

 

초록이 메세지를 여러 곳에 발행하고 싶다. 구독하고 있는 빨강이는 2곳이며, 실시간으로 발행 시 채팅이 전달되는 지 확인

 

pub/sub 기능은 멀티 서버 환경에서 채팅, 알림 등의 서비스를 구현할 때 흔히 사용

 

 

 

 

 


1. 초록 - publish

2. 빨강1 - subscribe

3. 빨강2 - subscribe

 

 

발행 시

 

"publish 채널명 메세지"

 

 

 

구독 시

"subscribe 채널명"

 

먼저 구독 후 발행해야함

 

 

발행 시 적었던 "hello this is a test message" 가 들어온 것을 확인할 수 있다.

 

 

 

채팅과 같은 서비스는 특정 서버에 서비스가 의존적이라 다수의 서버를 운용하면서 상대방에게 알림 또는 채팅을 보낼 때 pub/sub 사용

 

단점) 서버가 돌아가지 않다면, 저장되지 않아 유실될 가능성이 있음.

이럴 때 streams를 활용!

 

 

 

 

 

 

 

 

 

 

2. redis streams

 

pub/sub과는 다르게, streams은 메세지가 저장되어 소비자가 나중에 읽을 수 있음

 

 

 

 

 

마찬가지로 초록색에서 메세지를 발행해보고, 빨강색에서 메세지를 받아볼 예정

( 항상 먼저 빨강색에서 메세지 받기부터 해주기 기억)

 

 

 

1. 보낼 때

 

 

" xadd 스트림이름 * message "보낼 메세지" "

 

1) xadd - redis stream에 데이터를 추가할 때

2) test_stream - 스트림 이름

3) * - 메세지 고유의 IDF를 redis에서 자동으로 생성 (id 값 자동생성)

 

 

 

 

 

 

2. 받을 때

 

2

 

"xread block 20000 스트림이름 $"

 

1. block 20000 - 최대 20초(20000ms) 동안 대기

2. $ - 현재 마지막 메세지 이후에 오는 새 메세지를 기다림. (실시간으로 메세지를 기다림)

 

 

 

 

저장되었는 지 확인해보자

 

 

key로 조회 했을 때, test_stream이 존재하는 걸 볼 수 있고,

 

(- +는 처음부터 끝까지 조회)

xrange로 조회 시 데이터가 남아 있는 것을 볼 수 있다.

 

 

 

 

 

 

 

pub/sub과 stream의 차이!

 

 pub/sub은 일회성 메세지를 보내고 받는 형식이라면(일회성),

stream은 메세지를 자료구조에 저장되는 형식

 

 

 pub/sub은 서버가 죽어있으면 메세지가 유실될 가능성이 있어 안정성이 낮다.

stream은 안정적으로 메세지를 저장할 수 있음

 

 

사실 자료구조가 복잡해서 가능하지만 이런 형태로 사용할꺼면  인메모리 데이터베이스보다

더 다양한 기능을 지원하는 kafka를 쓰는 게 맞다!

 

 

 

 

 

 

 

 

 

티스토리툴바