프로젝트 현재 로직을 간단하게 설명하자면 대기열은 외부 redis를 활용하여 줄을 세운다.
이후에는 별도의 참가열에 한번 더 줄을 세우진 않고, 어플리케이션 내부에서 for문을 통해 처리하고 있다.

추가 구현하고자 하는 로직

기존의 로직은

(앞으로 이 화면은 대기 페이지로 통칭한다.)
해당 화면에서 입장하는건 모든 사용자들에게 동등하게 열려있다. 여기선 줄을 세우지 않는다.

그리고 응답 페이지로 입장해서 응답폼을 입력 후

(이 화면은 응답 페이지)

제출 버튼을 누르는 순간 사용자들을 줄 세우고 대기열 로직에 태운다.

사용자는 응답을 제출해야만 이 화면을 만날 수 있다.
이후 서비스 내부에서 대기열을 순차적으로 돌면서 일정 인원 씩 참가를 시켜준다.

그런데 사실...!!!

생각해보면 실제 서비스라면 대기 페이지에서부터 줄을 세워야 한다.

바로 이렇게 말이다.

사진 출처

그리고 대기순서를 보여주다가 0번이 되면 클라이언트가 고객을 응답 페이지로 이동을 시켜줘야 한다.
근데... 이걸 어떻게 구현하지?...🤔

구현 방법

일단 머리로 생각을 해봤을 때는 서버에서 프론트 쪽으로 0번 혹은 enter라는 고객의 상태값(이 사람 들여보내줘!!)을 던져주면 프론트에서 응답 페이지로 입장시켜주면 될 것 같다. 리다이렉트를 이용하면 되지않을까??!
근데 요즘 나에게 시간이 많지 않아서 전체적인 로직 변경 구현은 나중으로 미루기로 했다...⭐️

별도로 백엔드 코드의 간단한 로직 변경을 적용해봤다.

백엔드 코드 구현

변경 로직

백엔드 코드는 일단 Spring 애플리케이션 내부에 응답 리스트를 Map으로 저장했었는데 외부 메시지큐에 저장하는 방식으로 변경하려고 한다.

응답을 저장하는 로직과 DB에 저장하는 로직을 분리하면 결합도가 느슨해져서 안정적이고 확장성 높은 서비스 구현에 도움이 될 것이라고 생각했다.

이번 기회로 메시지큐를 처음 구현해보았다.
해당 글에서는 메시지큐 적용 코드만 간단하게 작성하려고 한다.

DTO

먼저 MQ에 넣기 위한 DTO 클래스들을 만들었다.

• 사용자의 전체 응답 리스트를 가지고 있는 요청 DTO (MQ에 담길 예정)
  

• 개별 응답 DTO
  

Producer

Consumer

별도의 처리를 하지 않아도 Queue에 데이터가 들어오면 Consumer가 자동으로 데이터를 읽어온다.
메시지의 발행과 소비가 비동기적으로 이루어지는 것을 몸소 체험할 수 있었다.

테스트

• 테스트하기 위한 컨트롤러
  

• API 요청
  

요청을 보내고 MQ를 확인해보니 1개의 데이터가 삽입되었다.

이후 Consumer 코드를 실행시켰고

로그에 데이터가 정상적으로 찍힌 것을 확인할 수 있었다.

메시지큐를 적용한 로직이 정상적으로 돌아가는 것을 확인했으니 추후에 전체적인 서비스 로직 변경 시 활용할 수 있겠다!