Pub/Sub Architecture

728x90

✅ 기본 개념

- Publisher : 특정 topic(또는 subject) 에 대한 이벤트를 발생시키고, 메시지를 시스템에 전송하는 주체

- Subscriber : 특정 topic들을 구독하고, 구독한 topic의 이벤트가 발생하면, 이벤트 메시지를 수신하는 주체

- Publisher와 subscriber는 서로의 존재를 모르며, 직접 통신하지 않는다.

- 제3의 요소가 publisher와 subscriber를 연결하며 메시지를 전달한다.

- Publisher와 subscriber가 publishing과 receiving 하는 동안 서로 연결을 지속할 필요가 없으므로 효율적이다.

- 최적의 효율을 위해, pub/sub 모델에서는 3가지 차원을 분리한다.

1️⃣ 공간 분리 (Space decoupling)

- Publisher와 subscriber는 서로의 존재를 알 필요가 없다.

- 그래서 서로의 IP주소와 포트번호도 몰라도 된다.

2️⃣ 시간 분리 (Time decoupling)

- Publisher와 subscriber는 동시에 일을 수행하지 않아도 된다.

3️⃣ 동기화 분리 (Synchronization decoupling)

- 양쪽이 작업하는 동안, 반대쪽의 작업이 중단될 필요가 없다.

- 쉽게 말하자면, publisher가 publishing하는동안 subscriber의 receiving 작업이 중단될 필요가 없으며,

subscriber가 receiving하는 동안 publisher의 publishing 작업이 중단될 필요가 없다.

✅ 메시지 필터링

- 서버는 각 subscriber들이 구독한 메시지만 수신하도록 메시지를 필터링하여 전송하여야 한다.

🐥 Subject-based filtering (Topic-based filtering)

- Subscriber들은 관심 있는 특정 토픽을 구독하고, 서버는 해당 토픽을 구독한 클라이언트(subscriber)들에게 해당 토픽의 메시지를 라우팅한다.

- Topic은 계층 구조로 되어 있고, 각 계층은 '/'로 구분되어 있다. (예시: "home/living-room/temperature")

- 클라이언트들이 topic 의 계층 구조를 정확히 알아야만 한다는 단점이 있다.

🐥 Content-based filtering

- Subscriber들은 특정 filter expression을 구독하고, 서버는 메시지의 내용에 기반하여 적절한 filter expression을 구독한 클라이언트들에게 메시지를 라우팅한다. (filter expression 예시: "tracking-number = '1234',")

🐥 Type-based filtering

- Subscriber들은 특정 타입이나 클래스의 메시지를 구독하고, 서버는 메시지의 타입을 확인한 뒤 해당 타입을 구독한 클라이언트들에게 메시지를 라우팅한다.