Pub/Sub
특징
-
publisher - message broker - subscriber 형식으로 이루어져 있다.
-
메세지 기반 미들웨어
-
publisher가 event 발생시 message broker 에게 알려주고 해당 토픽 혹인 컨텐츠를 구독하고 있는 subscriber에게 메세지를 전달하는 방식이다.
- publisher가 발행하는 모든 메세지를 받는 것이 아닌 subscriber가 원하는 event에 해당하는 메세지만 받게 된다.
⇒ 필터링- topic
- content
- hybrid
- publisher가 발행하는 모든 메세지를 받는 것이 아닌 subscriber가 원하는 event에 해당하는 메세지만 받게 된다.
-
동기방식인 request, response 형식이 아닌 비동기형식이다.
- subscirber가 메세지를 쌓아둘 수 있기때문에 publisher가 계속 기다릴 필요가 없다.
-
pull technology : client가 아닌 server에 의해 시작되는 communication이다.
-
publisher와 subscriber가 message broker를 통해 연결되어 있으므로 서로를 모른 상태로 메세지를 보내게 된다.
-
장점
- publisher와 subscriber가 서로의 시스템을 파악하지 않아도 되서 간편하고 용이하다.
- 또한 확장성이 좋고 동적인 네트워크 구조를 형성할 수 있어서 좋다
-
단점 : publisher가 의도한대로 메세지가 보내졌는 지 알 수 없다. crash가 발생하여 메세지를 전송받지 못해도 subscriber를 알 턱이 없다.
-
서버와 클라이언트 둘 중에 하나가 running이 아니여도 backlog를 사용하기에 메세지를 전달할 수 있다.
-
단점
- 시스템 규모가 커지면 pub/sub은 처리량에 있어서 불안정하게 된다. ⇒ 데이터 센터
- 많은 트래픽이 몰리면 local area network를 shut down 해버리는 문제가 있다.
- broker를 사용하면 pub/sub일 경우 in-band 형식( 메인 데이터와 컨트롤 데이터를 같은 채널을 통해 전송한는 방식)을 사용하는데, 이때 악의적으로 데이터를 조작하면 보안에 문제가 생길 수 있다.
kafka, redis
- kafka : group의 개념이 있다. event가 발생 시 group 내 한명의 subscriber만 메세지를 받아야하는 경우
- 큐를 사용하지 않고 topic이라는 카테고리에 데이터 집합을 저장
- ex ) 회원가입시 user api(publisher) 에서 coupon을 발행하라는 메세지를 coupon api (subscriber )에게 전송하는 경우
- redis : group의 개념이 없다. message broker는 tv의 channel과 같은 개념으로 해당 channe을 구독하고 있는 모든 subscriber에게 메세지를 전달하게 된다.
- ex) 권한 api(publisher)에서 권한정보가 변경되어 유저의 권한을 변경하라는 메세지를 유저 api (subscriber )에게 전달하는 경우 → 모든 서버에 있는 유저의 권한이 같이 변경되어야한다.
Message Queue
- Message Oriented Middelware(MOM) 개념을 구현한 시스템
구조
- publisher가 event 발생 시 queue에 메세지를 저장하고 해당 queue를 소비하려는 consumer 중 한명이 해당 message를 소비하게 된다.
- 큐안에 messageA가 있고 messageA를 consumerB가 소비하면 consumerA는 messageA에 대해 아무것도 모르게 된다.
- pub/sub은 publisher가 event가 발생하면 해당 topic을 구독하고 있는 모든 subscriber에게 브로드캐스팅으로 메세지를 전달한다.
참조
Publish/Subscrib (pub/sub) system
