현 프로젝트 구조는 다음과 같습니다.
앱의 주된 기능을 수행하는 본 서버와 채팅 관련된 기능을 수행하는 채팅서버로 분리되어 있습니다.
두 서버는 같은 데이터베이스에 crud를 수행합니다.
채팅서버에서 채팅로그를 저장할 때, 채팅 서버에서 rabbitMQ에 저장하고자 하는 데이터를 넣고, 이 이벤트가 발생하면 데이터베이스에 저장하는 방식으로 구현했습니다.
이렇게 구현하면 어떤 이점이 있는지 궁금합니다.
+팀원이 저를 설득할 때 했던 말은 보통 채팅기록을 저장할 때,
비동기로 처리해주기 위해 RabbitMQ를 사용한다곤 했습니다.
제 생각엔 이 구조면 비동기고 뭐고간에 의미없다고 생각하는데 뭐가 맞는지 모르겠습니다..
- dc official App
그걸 왜.. 남한테.. 물어..
니가 태어난게 세상에 이점이 있는지가 궁금해진다
혹시 이대로 구현하는건 맞는 방식인가요..? 전에 메시지큐를 쓰라곤 하셨는데 데이터 손실문제를 제외하면 이점이 없는거 아닌가요? 저런 구조면 비동기를 하나 동기로 하나 똑같은거 같아요... - dc App
ㅋㅋㅋㅋㅋㅋㅋㅋ
응애 - dc App
아니 순서가 바뀐거 아님? 채팅서버에서 채팅로그를 저장할 때, 채팅 서버에서 rabbitMQ에 저장하고자 하는 데이터를 넣고, 이 이벤트가 발생하면 데이터베이스에 저장하는 방식으로 구현했습니다. 이유가 있으니까 이렇게 구현한거아님? 근데 왜 역으로 이점을 묻노
데이터 손실문제때문에 한다는거는 이해했는데 비동기로 처리한다는거에서 의문이 듦.. 이 구조면 비동기로 처리한다 한들 동기로 처리하는거랑 다른지 모르겠음.. - dc App
벌크 처리가 가능하고 db 처리량이 밀려도 버퍼 역할을 해줄 수 있잖아 db 병목 걸리면 뒤에 시스템들 줄줄이 블록되는거도 막아주고
그리고 니가 지금 단순한 구조라서 와닿지 않는건데, 단순 db 인서트 1행 하는게 아닌 경우도 생각해봐라 인덱싱을 한달지..
새로운 시각을 주셔서 감사합니다.. 좀 더 생각해볼게요 - dc App
넘 톡시한거아니냐 - dc App
채팅 로그가 채팅 메세지를 말하는 거야? 맞다면 메시지 큐를 쓰긴함. 근데 단순히 DB에 저장하는 용도 외에 채팅을 보낸 상대방이 접속해 있느냐 아니냐에 따라 어디로 메세지를 보낼지 라우팅하는 용도로 쓰는듯 단순 로그 저장용도라면 로그가 여러 서버에서 송신되고 로그마다 저장하는 곳이 달라서 관리하기 귀찮을 때 메세지큐를 쓸 수 있을 거 같지만 지금 상태면 굳이?
게이야 단순 로그도 중간에 버퍼나 큐를 둔다
네 채팅 메세지 말하는거 맞아요. 지금은 단순히 데이터베이스에 저장하는 용도로만 메시지 큐를 도입하긴 했는데 데이터 손실문제를 제외하면 큰 이점은 와닿는게 없어서요.. 답변 감사합니댜 - dc App
데이터 손실 문제 때문에라도 충분히 쓸만하다고 생각함 단순로그라도 그런 관점에 있어선 필요하긴 하겠네영
데이터 손실 문제라기보다는, 로그 입력이 메인 로직의 성능에 영향을 줘선 안되기 때문이라고 보는게..
그러니까 대기햄말은 메시지큐를 안쓰면 커넥션 고갈되면 작업을 수행중인 워커쓰레드가 아무것도 안하고 빙시처럼 가만히 있으니까 도입하는게 주 요인이라는거죠? 데이터손실문제 해결은 부수적인 이점인거고 - dc App
윗댓글에서말한db병목땜에처리밀린다는거랑동일한맥락인듯
단순 로그의 경우에는 그렇다는거지
이점은 상황에 따라 달라짐
그냥 우체통역할임 (벌크/버퍼) 근데 이거 모르고 왜 쓰는거지 - dc App
그냥 레디스 펍섭으로 서버 묶고 메세지쏴주고 채널들어갈때 디비에서 읽으셈... 드럽게 비싼 MQ를 왜 그렇게 쓰는거야
저건 그 용도가 아니잖아
아 저장을 mq에 하겠다고.. 대체왜...??
뭔소리야
나 정신나갓나봐