About Redis Pub Sub - YJGwon/connectruck GitHub Wiki

기본적인 동작 흐름

channel을 통해 메세지 송/수신, redis 고유 TCP 프로토콜인 RESP로 통신

각 client는 하나 이상의 channel을 subscribe

publish할 때는 channel 지정하여 publish

• 구독, 발행 시 channel 존재 여부 또는 channel의 구독자 정보 알 필요 없음

구독

> SUBSCRIBE first second
subscribe
first
1
subscribe
second
2

응답 : subscribe + 채널 이름 + 현재 구독중인 채널 수

발행

> PUBLISH second Hello

수신

message
second
Hello

client의 경우 하나 이상의 channel을 구독하기 시작하면 구독에 관련된 명령(SUBSCRIBE, UNSUBSCRIBE 등)만 할 수 있음 (”subscribed state”)

• 구독 중인 모든 채널에 대해 구독을 해지하면 subscribe state 해제

내부 구조

서버에서는 dictionary 형태로 구독 정보 저장

• key - channel 이름, value - client 정보 list

client에서는 자신이 구독한 channel 이름 저장

• unsubscribe 명령 및 subscribed state 관리하는 용도

publish할 때 → 해당 key에 등록된 client list 순회하며 메세지 전송 (O(N), N = 구독중인 client 수)

vs Kafka

	kafka	redis pub/sub
이벤트 저장	O (at least once 보장)	X (구독하는 client가 활성 상태 아니면 그대로 증발)
수신 횟수	consumer group내에서 1번만	해당 channel의 모든 subscriber가 수신
메세지 전달 방식	pull 방식 (consumer쪽에서 일정 주기로 polling 요청)	push 방식(publish하는 즉시 모든 subscriber에게 전달)

주의할 점

pattern subscribe

redis pub/sub은 PSUBSCRIBE라는 명령어를 지원 - channel 이름 특정하지 않고 패턴에 해당하는 channel에 발행되는 메세지 구독

이 때 내부 구조를 보면 pattern - client 쌍을 linked list로 저장해두고 publish할 때 모든 node를 순회하며 패턴에 매칭되면 메세지 발송

• pattern이 같아도 서로 다른 node로 저장됨!
• 결과적으로는 현재 패턴 구독 중인 모든 client 개수만큼 패턴 매칭을 하는 것

따라서 pattern 구독을 사용하면 publish의 시간복잡도가 O(N + M) - N = channel 이름에 대해 구독하는 client 수, M = 현재 구독중인 모든 pattern subscriber 수

클러스터링 환경에서의 사용

Redis가 클러스터링 되어있는 경우, 그냥 publish하게 되면 모든 node에 이 메세지가 전달되고 각 노드에서 자신이 가지고 있는 client 정보 탐색하여 메세지 발송

• → 불필요한 통신이 많음

이를 극복하기 위해 version 7부터 sharded pub/sub 제공

• 기존 redis sharding시 쓰이는 hash 알고리즘으로 channel을 해시하여 sharding하고, publish할 때 해당 node에 메세지 전달
• SPUBLISH, SSUBSCRIBE 등 기존 명령어에 S 붙이면 sharded channel이 됨

references

• Redis Pub/Sub | Redis
• Pub/Sub Introduction Redis (redisgate.kr)