Skip to content

2021 02 04 회의록

Jump to bottom
yeen edited this page Feb 4, 2021 · 1 revision

채팅 관련 이슈

기본적으로는 stomp 프로토콜 사용중

  1. /socket : socket 연결.

  2. /pub/chat : 현재 방에서의 채팅. /sub/room/방번호 의 subscriber에게 메시지 전송

  3. /pub/feedback : saveRedis 메소드를 사용하며, historyId값을 포함한 메시지 내용을 rightpush로 저장.
    saveRedis와 별개로 Listener인 RedisSubscriber 클래스에서는 /sub/feedback/historyId 로 메시지를 전송한다.

  4. /api/message/feedback : redis에 모아둔 피드백 메시지를 DB로 옮긴다.
    단일 토픽에 있는 수많은 queue 데이터를 history Id로 stream → writtenUser, targetUser, studyHistory를 전부 db 조회해서 찾은 다음 feedbackDto객체로 변환해 저장.

궁금했던 구조

  1. interceptor의 beforehandshake는 어떤 역할인지?

    • 아직은 미완성 상태 그치만 역할은 웹소켓에서 세션 검증을 위해 만들어 놓은 것
    • 웹소켓으로 들어온 소켓의 사용자가 유효한 사용자인지 검증하려고 했음
    • ChannelInterceptor (StompHandler에서 사용하는)와 다른 점은 HandshakeInterceptor 같은 경우 메세지 자체를 잡아오는게 아니라 HTTP 정보를 옮길 때 주로 사용하기 위한 용도라는 점?

  2. 클라 쪽에서 요청했다는 메시지 type의 의미?

    • 음 이건 그냥 메세지 dto 중에 하나인데 아무래도 클라이언트쪽에서 stomp 로 연결할 때 해당 연결이 채팅에 관한 연결인지 1:1 면접을 위한 연결인지 구분하도록 하기 위함인듯하다.

  3. sockJS().withJS 유무 두 개로 변경한 이유?

    • 기본 웹소켓으로만 연결할 경우 웹소켓을 지원하지 않는 브라우저나 혹여 모를 상황에 웹소켓 연결이 끊겼을 때를 대비하지 못한다.

    • 이러한 상황에 대비하여 WebSocket Emulation을 지원하는 것이 바로 SockJS 프로토콜

      WebSocket Emulation 이란,

      우선 WebSocket을 시도하고

      WebSocket 연결이 실패한 경우 HTTP-Streaming, HTTP Long Polling 같은 HTTP 기반의 다른 기술로 전환해 다시 연결을 시도하는 것.

    결국 WebSocket API를 사용할 수 없는 경우 런타임 시점에 코드 변경없이 WebSocket 이외의 대안으로 대체하도록 하기 위함

  4. redis는 현재 단일토픽이며, 토픽명은 studyRoomChat. 모든 feedback 메시지가 단일 queue로 쌓이는 구조가 맞는지?

    • 채널은 studyRoomChat 하나로 구성되어있고 들어온 모든 메세지는 해당 채널로 pub/sub 된다.
    • feedback 메세지 같은 경우 면접이 이뤄지고 있는 스터디 면접기록(key)에 해당하는 value = 리스트에 쌓이는 구조

  5. StudyHistoryId 이 값의 의미는?? vs GroupStudy

    • StudyHistoryId = 한사람의 면접 기록

  6. ChatController에 있는 BindingResult의 작동원리가 뭔지 모르겠음

    • binding result 는 dto의 객체가 올바르게 들어왔는지 검증하는 역할
    • 따라서 사전에 데이터들이 맞게 들어왔는지 체킹하여 service에서 비즈니스 로직을 처리함에 있어서 문제를 방지할 수 있음

생각해볼 점

  1. redis에서 feedback을 저장할 때마다 DB 접근횟수가 너무 많아 보인다.
    -> 서비스 커지면 DB connection pool 문제 생길 가능성이 있음.
  2. 1과 연관된 문제로, User 필드에 relation이 많은 이유??
    (저는 여기서 혼자했던 토이프로젝트 사수분들께 피드백받을 때, 현업에서는 가급적 relation 안만든다는 얘길 들었습니다. relation 걸었을 때 내부적으로 작동하는 쿼리 로직이 너무 복잡해져서 감당이 어렵다는 이유였습니다) → 맞습니다..!! ㅜ-ㅜ 연관된 것들이 많아서 처리하기 복잡한 부분들이 많이 있어요 ㅎㅎ → relation 문제가 해결되면, feedback 데이터를 NoSQL로 옮기는 것을 고려해볼 수 있을 듯.

우선 순위

Clone this wiki locally