반응형 전체 글72 Redis Pub/Sub 구현 (구독자모드의 제약 사항) Redis Pub/Sub을 사용하기로 하고 구현에 나섰다. 우선, 프로젝트 내에서 이미 Redis가 구현이 되어서 동작하고있는 상황이었기에, 간단하게 Pub/Sub 기능만 추가해주면 되는 상황이었다. 그러면 처음으로 Redis Pub/Sub을 공부하며 구현하고, 마주한 문제에 대해 정리해보려 한다. Redis Pub/Sub: Redis에서 지원하는 하나의 메세지를 여러 수신자에게 동시에 전송하는 실시간 통신으로 활용되어 서로 다른 서비스 간 메세지를 쉽게 주고받을 수 있다. 메세지를 발행하는 Publisher와, 해당 메세지를 구독하여 수신하는 Subscriber로 구성된다. Publisher는 특정 채널(Channel)에 메세지를 발행하고, Subscriber는 해당 채널을 구독하여 실시간으로 메세지.. 2024. 8. 21. 알림기능 DB 생성 알림 기능을 구현을 위한 DB 뼈대를 세우던 중 다양한 유형의 알림을 처리해야했다. 이 과정에서 서로 다른 DB에 있는 CP와 USER 두 유형을 대상으로 여러 유형의 알림(리뷰, 게시글, 댓글 등)을 관래해야 했고, 각각 다른 테이블을 관리해야 했다. 그리고, 외래키 제약 조건을 사용할 수 없는 상황에서 데이터 무결성, 확장성을 유지하기 위한 방법을 찾아보았다. 문제: 알림 받는 대상이 CP와 USER로 나뉜다. 알림의 유형 또한 리뷰, 게시글, 댓글 등 다양하다. 1. 외래 키 제약 사용 어려움 : 진행 프로젝트의 데이터베이스 분리 구조 때문에 CP에 외래 키 제약을 적용할 수 없어 데이터 일관성 유지 어려운 상황2. 확장성 문제 : 알림기능의 경우 추후 여러 기능에서 계속 추가 될 예정인데 기존의.. 2024. 8. 20. 알림기능 기술 선택(SSE, Redis Pub/Sub, Socket.IO) 채팅 기능에 이어 알림기능을 구현하게 되었다. 지난번에도 알림기능을 구현한 경험이있는데, 당시 시간도 촉박하고 아는것이 별로 없어 기술 선택시 다양하게 고려해보지 못했다. 하지만 이번에는 최종프로젝트인 만큼 여러 기술 중 우리의 서비스에 맞는 기술들을 엄밀히 고려해보려 한다.구현하려는 기능커뮤니티/리뷰의 새글 등록 및 댓글 등록시 알림읽음/안읽음 기능알림 클릭시 해당 게시물로 연결이번 구현하는 알림기능에서 필요한 부분은 이렇게 세 가지가 있다.해당 기능을 충족하는 기술 선택을 위해 여러 기술들에 대해 알아보았다. 고려 기술1. Server-Sent Events (SSE)특징:서버에서 클라이언트로 단방향 스트리밍을 제공.HTTP 기반으로 작동하며, 브라우저와의 호환성이 높음.연결 유지 비용이 비교적 낮음... 2024. 8. 12. SSL 연동 후 Socket 연결 트러블슈팅 문제로컬 환경에서 소켓.io를 이용해 채팅 기능을 성공적으로 구현하였으나, 서버에 배포 후 SSL을 적용한 상태에서 소켓 연결이 되지 않는 문제가 발생했습니다.해결 방법해당 부분에서 문제가 생길 수 있는 여러 부분을 살펴보았습니다.클라이언트 측에 ‘wss://’ 프로토콜이 아닌 ‘ws://’을 ****사용하고있지 않은지, ****방화벽 설정을 확인하고, WebSocket을 사용하는 포트가 열려 있는지 등 여러 문제 가능성을 고려하였고 문제를 분석하기 시작했습니다.문제 분석로컬 환경에서 Socket.io가 정상적으로 동작하였으므로, 배포 환경에서의 설정 문제 의심SSL을 적용한 HTTPS 통신이 실패한 것으로 보아, 소켓 요청이 제대로 프록시되지 않고 있는 것해결책 모색socket.io 공식 문서에서 SS.. 2024. 8. 11. socket io 1:1 채팅 구현 (2)jwt 토큰 전달 1:1 채팅을 구현하며 두번째로 생각이 많이 되었던 부분은 jwt를 통한 토큰 전달 부분이었다. 기존 공통 jwt strategy와 guard를 이용해 채팅을 하나씩 구현해나가는 중 jwt쪽에서 계속적으로 에러가 발생했다. 처음에는 원인을 찾지 못했는데, 하나 둘 찾아보던 중 socket 같은 경우 jwt를 전달하는 방식이 다르다는 것을 알게 되었다. HTTP와 WebSocket의 차이점HTTP : 요청-응답 방식으로 동작. 클라이언트가 서버에 요청을 보내고, 서버는 요청에 대한 응답을 반환. 이 과정에서 클라이언트는 요청 헤더에 JWT 토큰을 포함시킬 수 있으며, 서버는 이 토큰을 검증하여 사용자의 인증 상태를 확인할 수 있다.WebSocket : 클라이언트와 서버 간에 지속적인 연결을 유지하는 프.. 2024. 8. 2. socket io 1:1 채팅 구현 (1)채팅방 DB 저장 socket.io를 통한 1:1 채팅을 구현했다. 이 과정을 진행하며 여러 부분에서 고민이 되었는데, 그 중 고민되었던 부분들을 정리해보려 한다.1. 채팅방 각 유저 id 에 대해 각자의 DB 칼럼에 어떻게 알맞게 넣을 것인가?문제이번에 구현하는 채팅 기능의 경우 2가지 도메인에서 접근이 가능하다. 1. 서비스 유저 2.CP(Content Provider) 그렇다보니 chat 테이블의 칼럼도 userId와 cpId로 나눠져있다. 채팅방에 입장할시 서비스 유저 입장에서는 CP의 ID를 입력하고 들어올 것이고, CP의 입장에서는 서비스 유저의 ID를 입력하고 들어올 것이다. 이 상황에서 데이터베이스에 채팅방을 저장할 때 cpId와 userId가 어떻게 적절히 분류되어서 들어가게 만들 수 있을 것인가?해결과정.. 2024. 8. 1. 소켓 1:1 채팅 기능(구현했던 알림 기능과 다른점은?) 이전 팀프로젝트에서 socket.io를 통해 서비스 알림 기능을 구현했다. 이번 최종프로젝트에서는 운좋게 socket.io를 통해 1:1 채팅을 구현할 수 있게 됐다. 그래서 오늘 해당 기능을 위해 약간의 공부와 기본 구성을 만들었다. 비슷한듯하면서도 응용이 필요한 1:1 채팅기능을 정리해보겠다. 알림 기능과 1:1 채팅의 차이점은 무엇이 될까?데이터 구조 및 저장알림: 보통 단방향 데이터 흐름으로, 서버에서 클라이언트로 짧은 메시지 전송.채팅: 양방향 데이터 흐름으로, 메시지의 송수신이 빈번하며, 메시지 기록을 저장하고 조회할 필요가 있음.실시간 통신알림: 특정 이벤트 발생 시 알림을 푸시.채팅: 지속적인 연결을 유지하며, 메시지 송수신을 실시간으로 처리.유저 인터페이스알림: 간단한 UI로 알림 리스.. 2024. 7. 29. Linux 명령어 정리 github 및 터미널에서 배포 등을 진행하며 간단한 Linux를 사용해 왔다. Linux 명령어를 잘 알면 개발하는 데 있어 훨씬 효율적이고 편리하다는 것을 알고 있지만, 항상 과제와 프로젝트를 끝내기 위한 급한 마음으로 사용하다 보니 막상 제대로 정리해 본 적은 한 번도 없다. 캠프도 끝이 얼마 남지 않았으니, 이번 기회에 그동안 필요한 것만 쏙쏙 빼서 사용하던 Linux의 명령어들을 정리해보려 한다. 1. 파일 및 디렉토리 관리- ls : 현재 디렉토리의 파일 목록을 출력. 옵션 추가해 파일의 자세한 정보 확인 가능ls -l - cd : 디렉토리 이동 명령어. 경로를 입력해 원하는 위치로 이동 가능cd /home/user/Documents - mkdir : 새로운 디렉토리 생성mkdir new_di.. 2024. 7. 24. 이전 1 2 3 4 ··· 9 다음 반응형
