앞서 보았던 Observer 패턴은 알림을 수신하고자 하는 Observer가 이벤트를 실행하는 주체 Publisher에 등록해야 한다. 즉, 옵저버 패턴은 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 알림이 가고 자동으로 정보가 갱신되는 보통 1:N 의 관계를 성립된다. 강한관계를 갖는 Observer 패턴과 달리 pub/sub 패턴은 느슨한 관계를 갖는다.
pub/sub 패턴 : 메세지 기반의 미들웨어로, 알림을 수신하려는 객체(Subscriber)와 이벤트 발생 객체(Publisher) 사이에 위치하는 Event Channel을 두게 된다. Publisher는 Subscriber를 모른체로 이벤트 발생 시 Event Channel에게 메세지를 넘겨주고(push), 중간 컴포넌트는 이벤트들을 필터링해서 받아야 할 수신자들에게 보내준다. 즉, subscriber는 publisher에 대한 정보 없이 자신의 Interest에 맞는 메시지만을 전송 받는 것을 말합니다. 응답과 상관없이 중간 객체를 건너가기 떄문에 비동기 방식이다.
장단점
Observer 패턴 대비 장점:
- 직접적인 관계가 아니기 때문에 코드 관리, 재사용성, 안정성이 높다.
- Publisher 관점에서 Subscriber들을 일일히 관리하지 않는다.
단점:
- 기존의 시스템은 확실하게 직접 통신해서 목적지까지 메시지를 확실하게 전송할 수 있었다. 하지만, Pub/Sub시스템은 미들웨어를 통하기 때문에 의도한대로 전달하지 못할 수도 있다.
Kafka 예시
예제
Redis, RabbitMQ, Kafka
메세지 큐(Message Queue, MQ)
프로세스가 req,res가 아닌 데이터를 교환할 때 사용하는 통신방법. 메시지 지향 미들웨어(MOM) 개념을 구현한 시스템으로 비동기 메시지를 사용하는 프로그램 간 데이터 송수신 방법이다. 기존에 분산되어있던 데이터 처리를 한 곳에 집중하면서, 메시지 브로커를 두어 필요한 프로그램에 작업 분산하는 것이 목적이다. 보통 대용량 데이터 처리 배치 작업, 채팅, 알림 등 쓰인다.
장점:
-
비동기: 동기식 req,res 방법이면, 끊임없이 메시지를 주고받는 채팅시스템에 유연하게 대처하지 못하게 된다. 수백명의 사람이 채팅방에 들어와 있을 때, 한 사람의 네트워크 상태가 좋지 않아서 그 사람이 보낸 메시지가 제대로 처리되지 않고 있는 상황이 발생하면 이로 인하여 나머지 수백명의 사람이 해당 메시지의 완전한 처리에 대한 응답이 올 때가지 메시지를 전송하지 못하게 된다.
-
Decoupling: 어플리케이션과 분리
-
Scalable : 다수의 프로세스들이 큐에 메시지 보낼 수 있다.
출처:
https://creakycogwheel.tistory.com/entry/캡스톤-프로젝트메시지-큐란 [삐걱대는 톱니바퀴처럼]
https://blog.naver.com/PostView.nhn?blogId=dktmrorl&logNo=222117711303&categoryNo=0&parentCategoryNo=0&viewDate=¤tPage=1&postListTopCurrentPage=1&from=postView
https://2kindsofcs.tistory.com/6
