Pub/Sub 모델 - Redis vs RabbitMQ

Redis — 인메모리 Cache 서버

• Key-Value를 이용해, Celery가 처리할 작업을 보낸 후 Cache에서 해당 Key 제거
• Database에 접근하기 전, 메모리에서 Cache를 가져다 쓴다는 점에서 속도가 빠름
• 지속성이 중요하지 않고, 약간의 손실을 견딜 수 있는 짧은 보존 메시지에 적합

RabbitMQ — 메시지 브로커

• 메시지를 다른 대기열로 보낼 수 있는 라우팅 시스템을 갖춤
• 메시지 우선순위 지원
• 크고 복잡한 메시지에 적합
• 속도보다 지속성이 중요한 서비스에 적합

Pub/Sub 패턴

• 메시지 모델 중의 하나로 발행(Publish)과 구독(Subscribe) 역할로 개념화 한 형태

• 발행자와 구독자는 서로에 대한 정보 없이 특정 주제(topic or channel)를 매개로 송수신한다.

• 메시징 미들웨어 제품들 : kafka, RabbitMQ, ActiveMQ 등이 있다.

메시징 미들웨어 장점

• 비동기 : 통신의 비동기 처리
• 낮은 결합도 : 송신자와 수신자가 직접 서로 의존하지 않고 공통 미들웨어에 의존
• 탄력성 : 구성원들간에 느슨한 연결로 인해 일부 장애가 생겨도 영향이 최소화됨

RabbitMQ는 원래 이 구조이고, Redis도 이 구조로 구현이 가능했다!

Redis의 Pub/Sub 특징

• 메시지가 큐에 저장되지 않음.
• kafka의 컨슈머 그룹같은 분산처리 개념이 없음.
• 메시지 발행시 push 방식으로 subscriber들에게 전송
• subscriber가 늘어날수록 성능이 저하

Redis의 Pub/Sub는 언제 사용할까?

• 실시간으로 빠르게 전송되어야 하는 메시지

• 메시지 유실을 감내할 수 있는 케이스(메시지의 한시적으로만 유용한 케이스)

• 최대 1회 전송(at-most-once)패턴이 적합한 경우

• Subscriber들이 다양한 채널을 유동적으로 바꾸면서 한시적으로 구독하는 경우

• 가장 대표적인 예가 채팅방이다.

왜 채팅방이 redis가 유용한가?

소수만 사용하는 작은 채팅 시스템은 상관없지만, 많은 사람들이 사용하는 채팅 데이터는 Redis같은 NoSQL가 많이 사용된다.
짧은 시간에 많은 데이터 입력이 처리가 되고, 한정된 규모의 복잡성이 높은 데이터에서 단순한 대량의 데이터가 쌓이는데
조회, 삽입이 빈번하게 일어나면 RDBMS의 경우 Lock이 자주 발생할 수 있기 때문이다.

redis로 채팅방 구현은 다음 블로그를 참고
https://velog.io/@mooh2jj/Redis-pubsub-채팅방-구현

---

참고

https://medium.com/@nemesis1825/redis%EC%99%80-rabbitmq%EC%9D%98-%EC%B0%A8%EC%9D%B4-af48dbe9a7ed