해결된 질문
작성
·
87
답변 2
0
안녕하세요. 수강자님
알림의 경우 단순 큐로도 구성이 가능한데, 굳이 pub/sub으로 하는 이유는 느슨한 연결을 통한 확장성 때문에 보통 pub/sub의 형태로 구현합니다.
단순 알림 기능 이후에 여러가지 채널로 알림을 확장하기 용이합니다. 단일 컨슈머 호출일 경우 기능이 제한적이기 때문에 추가적인 확장시 로직 변화가 pub/sub에 비해서 큽니다.
큐가 하나만 생성되고, 리스너도 하나만 붙어서 한 번에 하나의 컨슈머만 메시지를 처리하는 경우보다 여러 subscriber를 두고 각각의 독립된 sub가 각자의 부여된 역할을 처리하는 것이 확장성 확보가 되고 기능추가, 상호 영향도에서 장점이 있습니다.
답변이 되었길 바랍니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다. jhj13062004님.
질문해주신 Pub/Sub 구조에 대해 설명드리겠습니다.
Pub/Sub 구조는 여러 서비스 혹은 복수의 클라이언트가 동시에 동일한 정보를 받아야 하는 상황에서 매우 유용합니다. 특히 알림 시스템에서 그 필요성이 두드러집니다.
엇갈린 메시지 수집 및 분배: 알림 같은 경우 다양한 이벤트(로그인, 메시지 도착, 시스템 에러 등)가 발생할 수 있으며, 이러한 이벤트를 실시간으로 여러 사용자나 시스템에게 전달해야 할 때 Pub/Sub 구조는 적합합니다. 발행자(Pub)가 메시지를 특정 채널에 발행하면, 그 채널을 구독(Sub)하고 있는 모든 수신자에게 메시지가 전달됩니다.
확장성과 독립성: Service 하나에서 알림을 처리하면서도, Pub/Sub 구조는 확장성을 높일 수 있는 장점이 있습니다. 만약 추가적인 기능이 필요하거나 새로운 서비스들이 추가되어야 할 경우, 각기 구독 방식만을 설정하면 되기 때문에 상대적으로 시스템 구조 변경이 용이합니다.
다양한 클라이언트 지원: 다양한 종류의 클라이언트에서 알림을 받도록 설계해야 하는 경우, Pub/Sub 패턴이 유연성을 제공합니다. 각 클라이언트는 필요에 따라 독립적으로 채널을 구독할 수 있습니다.
전통적인 중앙 집중형 아키텍처에서는 모든 클라이언트가 직접 중앙 서버와 통신해야 하기 때문에 서버의 부하가 증가할 수 있습니다. 반면, Pub/Sub 구조에서는 브로커가 중앙에서 메시지를 관리하고 분배하므로 부하가 분산됩니다.
질문자님의 이해를 돕고 관련 강의 정보를 기반으로 유사한 질문의 링크를 추천합니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
감사합니다!!