🔴 Redis - Pub & Sub

아래에서 다루는 코드는 Github 를 통해 확인하실 수 있습니다.

📬 Redis Pub/Sub 이란?

Pub/Sub (Publish/Subscribe)은 메시지를 보내는 사람(Publisher)과 받는 사람(Subscriber)이 서로를 알 필요 없이, 특정 채널(Channel)을 매개체로 메시지를 주고받는 통신 패턴입니다.

Loose Coupling (느슨한 결합)

채팅방을 생각하면 쉽습니다. 발송자는 "채널"에 메시지를 던지기만 할 뿐, 누가 듣고 있는지 신경 쓰지 않습니다.
수신자 역시 누가 보냈는지 알 필요 없이 채널만 구독하고 있으면 됩니다. 이로 인해 시스템 간의 의존성이 극도로 낮아집니다.

Fire and Forget

메시지를 채널에 던진(Publish) 순간, Redis는 그 메시지를 보관하거나 수신 확인을 기다리지 않고 곧바로 잊어버립니다.

🔗 참고 자료

Redis 공식 문서 - Redis Pub/Sub

⚖️ Redis Pub/Sub vs 전문 MQ (Kafka, RabbitMQ)

"메시지 큐(MQ) 도입하자!"라고 할 때, Redis Pub/Sub을 쓸지 Kafka나 RabbitMQ를 쓸지 결정하는 기준은 '전송 보장 수준(Delivery Semantics)'에 있습니다.

물론 절대적인 것은 아니지만 가장 큰 관점이라고 생각합니다.

전송 보장 수준의 차이

At-Most-Once (최대 한 번 - Redis Pub/Sub)

메시지가 전송되거나, 아예 전송되지 않거나 둘 중 하나입니다.
네트워크가 끊기거나 구독자(Subscriber) 서버가 잠시 꺼져있을 때 발송된 메시지는 영원히 유실됩니다.

At-Least-Once / Exactly-Once (적어도 한 번 / 정확히 한 번 - Kafka, RabbitMQ)

메시지를 디스크나 메모리에 '저장(Store)'해 둡니다.
구독자 서버가 죽었다가 살아나도, 내가 읽지 못한 시점부터 다시 메시지를 쭉 읽어올 수 있어 데이터 유실이 없습니다.

왜 Redis는 메시지를 저장하지 않을까?

메시지를 큐에 쌓지 않고 브로드캐스팅한 뒤 곧바로 날려버리는 이유는 오직 '속도(Low Latency)'와 '가벼움'을 위해서입니다.

디스크 I/O나 Ack(수신 확인) 대기 시간이 전혀 없으므로, Redis Pub/Sub은 다른 전문 MQ들보다 압도적으로 빠르고 리소스 소모가 적습니다.

💡 어떤 서비스에 적합할까?
❌ 절대 쓰면 안 되는 곳
결제/주문 처리, 알림톡 발송 등 "단 1건이라도 유실되면 장애로 이어지는" 비즈니스 로직.
이 경우 Kafka, RabbitMQ, 혹은 Redis Stream을 써야 합니다.
✅ 어울리는 곳
실시간 채팅, 주식 호가창 업데이트, 접속자 목록 갱신 등 "잠시 끊겨서 과거 메시지 1~2개 놓쳐도, 최신 상태로 동기화되면 그만인" 가벼운 실시간 이벤트.

📡 구독 방식: 일반 채널 vs 와일드카드(Pattern)

Redis Pub/Sub은 특정 채널을 정확히 구독할 수도 있고, 정규식처럼 패턴을 이용해 여러 채널을 한 번에 구독할 수도 있습니다.

하지만 이 둘은 성능상 큰 차이가 있습니다.

일반 Channel 구독 (`SUBSCRIBE`, `PUBLISH`)

정확히 이름이 일치하는 채널만 구독합니다.

시간 복잡도: 매우 빠릅니다. $O(1)$에 가깝게 동작하며, 발송(PUBLISH) 시 구독한 클라이언트 수에만 비례하는 일정한 성능을 보여줍니다.

2. Pattern 구독 (`PSUBSCRIBE`)

news.* 처럼 와일드카드를 사용해 news.sports, news.it 등을 모두 수신합니다.

시간 복잡도: O(N) (N은 등록된 패턴의 개수)

⚠️ 주의사항 (패턴 구독을 지양해야 하는 이유):
패턴 기반 구독은 메시지가 발행될 때마다 해당 채널 이름이 기존에 등록된 모든 패턴 문자열과 일치하는지 비교(Matching)해야 합니다.
트래픽이 몰리는 상황에서 무분별한 패턴 구독은 Redis의 CPU 점유율을 급격하게 상승시켜 전체 시스템 장애(OOM, Timeout)를 유발할 수 있으므로 최대한 지양하는 것이 좋습니다.

🌐 클러스터(Cluster) 환경의 한계와 Sharded Pub/Sub

서비스가 커져서 Redis를 클러스터(Cluster)로 구성하게 되면, Pub/Sub 기능에 아주 치명적인 병목이 발생합니다.

기존 클러스터 환경의 비효율성 (Global Broadcast)

일반적으로 Redis Cluster의 키(Key) 값은 해시 슬롯에 따라 특정 노드에만 저장됩니다.

하지만 기존 Pub/Sub은 키 공간(Key Space)과 전혀 무관하게 동작합니다.

즉, 1번 노드에 PUBLISH로 메시지를 던지면, 1번 노드는 Cluster Bus를 통해 2, 3, 4번 등 클러스터 내의 "모든" 노드에게 메시지를 복사해서 브로드캐스팅(전파) 합니다.

노드 수가 많아지고 메시지 발행량이 늘어나면, 이 무의미한 복제 전파로 인해 네트워크 트래픽이 폭증(Network Storm)하게 됩니다.

🚀 Redis 7.0의 구원자: Sharded Pub/Sub

이 문제를 해결하기 위해 Redis 7.0부터 Sharded Pub/Sub 기능이 도입되었습니다.(SSUBSCRIBE, SPUBLISH 명령어 사용)

동작 원리

채널 이름도 일반 키(Key)처럼 해싱하여 특정 해시 슬롯(Slot)을 담당하는 단 하나의 노드(Shard) 내부에서만 메시지를 처리합니다.

효과

메시지가 전체 클러스터로 브로드캐스팅되지 않으므로, 네트워크 대역폭 낭비가 획기적으로 사라집니다.
클러스터 환경에서 Pub/Sub 트래픽이 높다면 반드시 Redis 7.0 이상으로 버전업하고 Sharded Pub/Sub을 사용하는 것이 실무 표준입니다.

🚀 Node.js 환경에서의 Pub/Sub 구현 예제

Node.js 환경(주로 ioredis 라이브러리 활용)에서 작성된 간단하고 직관적인 Pub/Sub 예시입니다.

💡 핵심 포인트: 반드시 커넥션을 분리하세요!
Redis 클라이언트는 SUBSCRIBE 명령어를 호출하여 구독 모드에 진입하는 순간, 다른 일반적인 명령어(GET, SET, PUBLISH 등)를 수행할 수 없는 상태가 됩니다.
따라서 아래 코드처럼 발행자(Publisher)용 클라이언트와 구독자(Subscriber)용 클라이언트를 반드시 별도의 커넥션으로 생성해야 에러가 발생하지 않습니다.

import { createRedisClient, disconnectRedisClient } from "../connection";

async function main(): Promise<void> {
  // 1. 발행자와 구독자를 위한 별도의 클라이언트(Connection) 생성 필수!
  const subscriber = createRedisClient();
  const publisher = createRedisClient();

  try {
    const channel = "test:notification";
    let messageRecived = false;

    // 2. 메시지 수신 이벤트 리스너 등록 (비동기 이벤트 기반 처리)
    subscriber.on("message", (channel, message) => {
      console.log(`[수신] 채널 ${channel} 로부터 메시지 도착: ${message}`);
      messageRecived = true;
    });

    // 3. 채널 구독 시작
    await subscriber.subscribe(channel);
    console.log(`채널 구독 완료: ${channel}`);

    // 4. 메시지 발행 (Publish)
    // 반환값(receivers1)은 현재 이 채널을 구독하고 있어 메시지를 받은 클라이언트의 수입니다.
    const message1 = "Hello, Redis Pub/Sub!";
    const receivers1 = await publisher.publish(channel, message1);
    console.log(`[발행] 메시지가 ${receivers1} 명의 구독자에게 전달되었습니다.`);

    const message2 = "Another message for subscribers!";
    const receivers2 = await publisher.publish(channel, message2);
    console.log(`[발행] 메시지가 ${receivers2} 명의 구독자에게 전달되었습니다.`);

    // 비동기 메시지 수신을 확인하기 위해 잠시 대기
    await new Promise((resolve) => setTimeout(resolve, 1000));
  } finally {
    // 5. 자원 반납
    await disconnectRedisClient(subscriber);
    await disconnectRedisClient(publisher);
  }
}

main().catch(console.error);

Subscribed to channel: test:notification
Message received on channel test:notification: Hello, Redis Pub/Sub!
Published message to 1 receivers
Message received on channel test:notification: Another message for subscribers!
Published message to 1 receivers

💻 코드 내용

커넥션 분리

subscriber와 publisher를 명확히 나누어 생성했습니다. 앞서 강조했듯, 구독 모드에 들어간 커넥션으로는 발송을 할 수 없기 때문입니다.

이벤트 드리븐 (Event-Driven) 수신

Node.js의 비동기 이벤트 특성을 완벽하게 살려 subscriber.on("message", ...) 형태로 메시지를 수신합니다.
블로킹(Blocking) 대기 방식이 아니므로 메인 스레드가 멈추지 않고 애플리케이션이 유연하게 동작합니다.

수신자 수 확인과 유실성(Fire and forget)

publish 메서드는 발송 후 현재 메시지를 정상적으로 수신한 구독자(Client)의 수를 정수로 리턴합니다.
만약 아무도 구독하고 있지 않은 채널에 메시지를 던졌다면 0이 반환되며, 해당 메시지는 어디에도 저장되지 않고 그대로 증발(유실)해 버립니다.

🍃 Spring Boot 환경에서의 Pub/Sub 구현 예제

Spring Data Redis에서는 RedisMessageListenerContainer라는 강력한 컨테이너가 구독 전용 커넥션과 백그라운드 스레드를 알아서 관리해 줍니다.

개발자는 커넥션 분리 같은 저수준의 고민 없이 비즈니스 로직에만 집중할 수 있습니다.

🔗 참고 자료

Spring Data Redis 공식 문서 - Pub/Sub

설정 (Configuration) 및 구독자 등록

RedisMessageListenerContainer 빈을 등록하고, 어떤 리스너가 어떤 채널(Topic)을 들을지 매핑합니다.

@Configuration
public class PubSubConfig {

    // RedisMessageListenerContainer
    // - Pub/Sub 구독 전용 커넥션을 내부적으로 생성하고 유지합니다.
    // - 등록된 MessageListener 에 수신 메시지를 비동기로 전달합니다.
    // - Spring 컨텍스트 시작/종료에 맞춰 자동으로 start/stop 됩니다.
    @Bean
    public RedisMessageListenerContainer redisMessageListenerContainer(
          RedisConnectionFactory connectionFactory,
          PubSubSubscriber subscriber) {

       RedisMessageListenerContainer container = new RedisMessageListenerContainer();
       container.setConnectionFactory(connectionFactory);

       // ChannelTopic: 정확한 채널명으로 구독 (일반 SUBSCRIBE)
       container.addMessageListener(subscriber, new ChannelTopic("news"));
       container.addMessageListener(subscriber, new ChannelTopic("sports"));
       container.addMessageListener(subscriber, new ChannelTopic("tech"));

       return container;
    }
}

수신자 (Subscriber) 구현

Spring Data Redis에서 제공하는 MessageListener 인터페이스를 구현하여 콜백 메서드를 작성합니다.

@Component
public class PubSubSubscriber implements MessageListener {

    private static final Logger log = LoggerFactory.getLogger(PubSubSubscriber.class);

    // 메시지 수신 시 호출되는 비동기 콜백 메서드
    @Override
    public void onMessage(Message message, byte[] pattern) {
       // message.getChannel(): 수신한 채널명
       // message.getBody(): 수신한 메시지 본문
       // pattern: 패턴 구독(PSUBSCRIBE) 시 매칭된 패턴, 일반 구독 시 null
       String channel = new String(message.getChannel());
       String body = new String(message.getBody());
       log.info("[Subscriber] 메시지 수신 - 채널: {} | 내용: {}", channel, body);
    }
}

발행자 (Publisher) 구현

메시지를 보낼 때는 우리가 평소에 캐시를 다루던 RedisTemplate의 convertAndSend() 메서드를 그대로 사용하면 됩니다.

발행자는, 별도의 컨테이너가 아닌 RedisTemplate 을 그대로 사용합니다.

@Component
public class PubSubPublisher {

    private static final Logger log = LoggerFactory.getLogger(PubSubPublisher.class);
    private final RedisTemplate<String, String> redisTemplate;

    public PubSubPublisher(RedisTemplate<String, String> redisTemplate) {
       this.redisTemplate = redisTemplate;
    }

    public void publish() throws InterruptedException {
       // 1. convertAndSend: 설정된 Serializer 로 메시지를 직렬화한 뒤 채널에 발행합니다.
       // (Java Lettuce 의 command.publish() 와 동일한 역할이나 Spring 에선 void 반환)
       log.info("=========publish=========");
       redisTemplate.convertAndSend("news", "Breaking: Redis 8.0 Released!");
       log.info("[Publisher] news 채널 발행 완료");
       Thread.sleep(100); 

       redisTemplate.convertAndSend("sports", "FIFA World Cup 2026 결승전 한국 우승!");
       log.info("[Publisher] sports 채널 발행 완료");
       Thread.sleep(100);

       // 2. 구독자 없는 채널에 발행 (Fire and Forget)
       // 구독자가 없어도 에러 없이 그대로 증발하며 정상 처리됩니다.
       log.info("=========구독자 없는 채널 발행=========");
       redisTemplate.convertAndSend("unsubscribed-channel", "아무도 듣지 않는 메시지");
       log.info("[Publisher] unsubscribed-channel 발행 완료 (수신자 없음)");
    }
}

📝 마무리

Redis Pub/Sub은 복잡한 설정 없이 애플리케이션에 압도적으로 빠른 실시간 메시징 파이프라인을 구축하게 해주는 훌륭한 도구입니다.

하지만 그 이면에는 "메시지 유실 가능성"이라는 뚜렷한 한계가 존재하므로, 이를 인지하고 채팅, 알림뱃지, 실시간 차트 갱신 같이 데이터 영속성이 크게 중요하지 않은 도메인에만 적재적소로 활용해야 합니다.

[Redis 완전 정복] Redis Pub/Sub : Loose Coupling Patern 구현 - With Java/Node/Spring

스택 시리즈🔴 Redis 완전 정복 시리즈 - 자료구조부터 Redis Cluster 까지