안녕하세요 "섹션2 8. Consumer간 작업 분배" 에서 질문 있습니다.

안녕하세요. 수강자님 컨슈머가 붙은 상태에서 정상적으로 메시지 큐에서 컨슈머에 전달 되면 정확하게는 처리중인 상태입니다.내부에서 따로 설정한 로직 (여기서는 슬립 후 처리) 이후 소진이 완료되고 ack 가 호출되고 이때가 소진이 완료된 시점이 됩니다. 로그가 빨리 올라와서 구분이 어려울 수 있으니 초 단위로 대기를 준 부분이 아직 처리가 안된 상태이고, 이 후에 메시지가 출력된 이후에 ack 가 전달되면 소비가 완료된 상태입니다.해당 강의는 메시지의 전달과 처리, 처리 완료 후 프로세스를 설명한 것이므로 초 단위 처리하는 부분이 실제 비즈니스 영역의 로직을 대체해서 소진 완료 이전에 로직을 실행하고 실행 후 act 가 날라가고 처리완료(소진완료) 된다고 이해하시면 됩니다. 감사합니다.

안녕하세요 섹션2. 12번 강의에서 질문 있습니다.

수강자님 안녕하세요. 특정한 뉴스를 발행하는 경우 데이터가 쌓이는게 우려될 경우 Direct로 설계하는게 맞고, 회원 등급별로 후처리 등을 염두에 둘 경우 팬아웃으로 써도 무방하빈다.pub/sub을 이용한 알람이 주 예제이고, 뉴스구독의 경우 fanout이든, direct이든 topic이든 구현하는 목적에 부합하는 방식으로 선택하시면 되는 문제라서 예제에서 단계별로 흐름을 설명하면서 각 exchange의 특징을 보여들릴 목적이지 뭘 선택하느냐는 실제 개발 환경에서의 목적에 따라 취사선택하시면 됩니다. 발행/구독 모델에 특정 사용자만 매칭해서 쏴야 할 경우, 전체에게 다 발행할 경우, 관심사 별로 유연하게 할 경우 해당 업무는 설계하는 목적에 따라 각각 direct, fanout, topic 을 선택해서 진행하시면 됩니다. 감사합니다.

Producer/Consumer 단위

수강자님 안녕하세요. 보통 우리가 메시지큐를 얘기할 때 인스턴스 단위로 얘기를 합니다.즉, 애플리케이션을 띄우는 단위를 말하고, 트래픽이 몰려서 큐처리에 행이 걸려 늦게 처리될 경우 이를 해소하기 위해서 서버 증설을 얘기하느데, 이 때 워커 노드(애플리케이션를 띄울 수 있는 서버 단위)를 늘리는 것을 메시징 미들웨어에서의 스케일 아웃이라고 표현합니다. 참고하시기 바랍니다. 감사합니다.

수업자료 제공 ?

안녕하세요. 수강자님 첫 강의에 보면 수업자료가 첨부 되어 있습니다.확인 부탁드려요. 감사합니다

컨슈머 서버 질문드립니다

안녕하세요. 수강자님 서비스가 복잡해질수록 발행하는 이벤트도 다양해지고 받는 쪽, 컨슈머도 이에 비례해서 증가하기 마련입니다. 싱글 도메인에 단순 비동기라면 적은 수의 메시지로도 문제가 없겠지만 복잡한 메시징 전송이나 상태 전송, 메시지의 컨펌 등 여러 레이어에 걸쳐 처리해야 할 경우 엠큐의 효과가 극대화 됩니다.브로드캐스팅 뿐 아니라 pub sub도 여러 도메인에서 활용 가능하므로 사용하기 나름입니다감사합니다

소스코드를 찾아가며 공부하는 시간이 더 많아야한다고하셨는데

안녕하세요. 수강자님 소스는 보통 사용하는 라이브러리를 뜯어보거나 Git에서 학습하고자 하는 소스들의 예제들을 찾아서 실행하며 로컬에서 분석해보시는걸 추천드립니다. 스프링의 경우 굉장히 다양한 유형별 소스가 Git에 많이 나와있고, 예제 단위로 정리한 repository도 많으므로 본인의 학습 목표에 따라 공식문서 뿐만 아니라 다른 라이브러리, 소스들을 찾아서 분석해보는걸 추전 드려요

DLQ 관련 질문

안녕하세요. 수강자님 auto 모드일때 미처리 (에러든 예외든) 된 상태는 unacked 가 맞습니다. DLQ도 어쨋든 큐이기 때문에 단순히 DLQ로 이동한 것만으로는 처리가 됐다고 보기 어렵고 컨슈머가 재 처리 해주어야 합니다. 다시 정상 처리 되었다면 ack 가 되어야 합니다.ack가 되지 않았다면 정상적으로 처리가 안됐다는 뜻이므로 consumer를 다시 점검해야 합니다.실제 처리 한건지 안한건지 코드에서 로그 등으로 확인해보고 MANUAL 모드에서 직접 채널에 basicAck, basicNack 으로 확인해시면 좀 더 이해가 빨리 되실겁니다. 감사합니다.

알림은 왜 pub sub 구조로 설계하나요?

안녕하세요. 수강자님 알림의 경우 단순 큐로도 구성이 가능한데, 굳이 pub/sub으로 하는 이유는 느슨한 연결을 통한 확장성 때문에 보통 pub/sub의 형태로 구현합니다.단순 알림 기능 이후에 여러가지 채널로 알림을 확장하기 용이합니다. 단일 컨슈머 호출일 경우 기능이 제한적이기 때문에 추가적인 확장시 로직 변화가 pub/sub에 비해서 큽니다.큐가 하나만 생성되고, 리스너도 하나만 붙어서 한 번에 하나의 컨슈머만 메시지를 처리하는 경우보다 여러 subscriber를 두고 각각의 독립된 sub가 각자의 부여된 역할을 처리하는 것이 확장성 확보가 되고 기능추가, 상호 영향도에서 장점이 있습니다. 답변이 되었길 바랍니다. 감사합니다.

Receiver를 여러개 하려면 어떻게하나요?

안녕하세요. 수강자님 컨슈머를 여러개 등록하는 방식은 여러가지 방식으로 접근할 수 있지만, 대표적으로는 크게 두가지 방식으로 나눌수 있습니다.일단 제일 편한건 워커노드를 여러대 설치하는 것이고, 두번째는 컨슈머를 통일한 애플리케이션에서 기동할 때 여러개 생성하는 방식이 있는데 이 방식에는 SimpleRabbitListenerContainerFactory 를 활용하거나 @RabbitListener를 활용하는 방식으로 처리할 수 있습니다. (사진)보시는 바와같이 SimpleRabbitListenerContainerFactory의 setConcurrentConsumers(동시 처리 수); 와 같이 지정해서 애플리케이션 기동시 동시처리 컨슈머를 생성할 수 있고, setMaxConcurrentConsumers로 최대치의 스케일을 설정할 수 있습니다.이렇게 하면 동일 큐에 여러 스레드가 붙어서 병렬로 소비할 수 있습니다. 두번째는 @RabbitListener(queues = RabbitMQConfig.QUEUE_NAME, containerFactory = "rabbitListenerContainerFactory")여기에 queues 에 원하는 큐 이름들을 설정하는 방법입니다.여러개의 큐 를 하나의 리스너에 바인딩 해서 queues = {"queue1", "queue2"}이런 형태로 설정해주실 수 있습니다.리스너를 여러개 두고 여러 큐, 여러 리스너를 등록해서 사용하시면 됩니다. 답변이 되었길 바랍니다. 감사합니다.

깃허브 step11 브랜치

안녕하세요. 수강자님 slack에 메시지 보내는 예제는 인터넷에 많이 있습니다. 해당 코드는 깃이나 인터넷 자료를 보시고, application.yml에 api-token과 channel-id 만 넣으시면 알림은 보내는데 문제 없을거에요.강의를 안만든 이유는 인터넷에 이미 관련 코드들이 많아서 강의로 설명할만한 주제는 아니라서 그렇습니다.지피티나 다른 llm 도구를 사용하셔도 금방 테스트 하실 수 있을거에요.감사합니다.