Skipalong's tistory

이번주는 노로바이러스에 걸려서 TIL 도 못쓰고 내내 몸져누워있었다. 오늘부터는 몸이 좀 나아져서 팀원들과 스터디를 재개했는데 알고리즘 풀이를 시작하였다. 오늘 푼 문제 중에 프로그래머스 추억점수라는 문제가 있었다. https://school.programmers.co.kr/learn/courses/30/lessons/138476 이 전에는 class Solution { public int[] solution(String[] name, int[] yearning, String[][] photo) { int[] answer = new int[photo.length]; for(int i=0; i

오늘은 우리 프로젝트에서 email인증과 캐시에 사용했던redis에 대해 정리해보겠다. 1. redis란? redis란 'Remote Dictionary Server'의 약자로, 고성능의 Key-Value 스토어입니다. 이는 메모리 기반의 데이터 구조 서버로서, 데이터베이스, 캐시, 브로커(Pub/Sub모델을 통해 실시간 채팅, 이벤트알림 등) 등의 역할을 수행할 수 있다. 빠른 응답 시간과 높은 확장성을 필요로 하는 다양한 서비스에서 널리 사용 2. redis의 collection redis 는 이렇게 다양한 자료 구조를 지원한다. 3. SingleThread redis는 싱글스레드를 사용하여 동시성문제가 생기지 않고 작업을 들어온 순서대로 하나씩 처리한다. 또 Redis 4.0부터는 'Redis Mo..

오늘은 기술면접 준비로 정리한 RDBMS의 정규화에 대해 정리해보겠다. RDBMS의 정규화에 대해 설명 데이터의 중복을 없애고 무결성을 향상 시키며 이상현상을 방지, 테이블 구성을 논리적, 직관적으로 만들며 데이터베이스 구조를 확장에 용이해지게 하기 위해 테이블의 키값과 컬럼값의 관계를 설정해주는 세 단계의 정규화 과정을 의미한다. 데이터의 중복을 줄이고, 무결성을 향상 DB 저장 용량 효율적 관리 가능 목적 : 데이터의 중복을 없애면서 불필요한 데이터를 최소화시킨다. 무결성을 지키고, 이상현상을 방지한다. 테이블 구성을 논리적이고 직관적으로 할 수 있다. 데이터베이스 구조를 확장에 용이해진다. 제 1 정규화(1NF) 테이블 컬럼이 하나의 값을 갖도록 테이블을 분리 시키는 것 만족해야 할 조건 어떤 릴레..

오늘은 기술면접 준비한 것 중 대용량 트래픽 처리법에 대한 부분을 정리해보겠다. 1. 트래픽 모니터링 트래픽 패턴을 모니터링하고 분석한다. 어떤 유형의 트래픽이 증가하였는지 어디에서 발생하고있는지 파악 2. 스케일 업(부품 업그레이드), 스케일 아웃(서버 증설) 서버자원을 확장한다 3. 로드 밸런싱 로드밸런서를 사용해 트래픽을 여러 서버로 분산시킨다 4. 캐싱 정적 콘텐츠를 캐시하여 반복적인 요청을 처리한다 5. DB최적화 데이터베이스를 최적화하고 인덱스를 조정,캐싱을 활용하여 성능을 향상 이중에서 캐싱을 해보았고 로드밸런싱에 대한 개념은 배운적이 있고, DB최적화에서 인덱싱은 해볼만 할 것 같다. 기술면접대비에서 배운 개념들을 내 프로젝트에 적용해보는 것이 즐겁고 개발자로서 한 걸음 더 성장하는 것 같..

전 TIL에 캐시를 저장해두고 캐시를 만료시키거나 삭제시켜주는 작업을 해두지 않으면 데이터의 변동이 있어도 캐싱된 데이터를 그대로 불러오게 되므로 잘못된 데이터를 가져오게 된다. 그래서 캐시를 만료시키거나 삭제해주는 작업을 해두는 것이 중요하다. 우선 만료시키는 방법은 전에 올린 CacheConfig 클래스에서 Map 형태로 CacheName을 키로 사용해서 Value 에 entryTtl(Duration.of~) 형식으로 값을 주어 CacheName별로 만료시간을 따로 정할 수 있다. @Override @CacheEvict(cacheNames = CacheNames.FEED, key = "#user.userId") public void uploadPost(User user, String content, ..

오늘은 길다면 길었고 짧다면 짧았던 최종프로젝트를 마무리하는 발표회가 있었다. 발표를 무사히 마무리하고 튜터님들이 찾아와서 우리 프로젝트와 관련된 질문들을 주셨는데 그 부분에 대한 정리를 휘발되기전에 정리를 해 두어야 할 것 같아서 정리를 해보겠다. 우선 질문을 굉장히 많이 받았는데 좋아요의 동시성문제를 파악하고도 적절히 처리해주지 않은 결정 이 부분은 사실 질문에 대한 답변이라기보다는 질책(?) 피드백(?)과 같은 부분이었다. 백엔드 개발자는 프론트단에서 비정상적인 상황에 대해서도 대응을 해주어야 한다고 하셨고, 이렇게 문제점을 파악하고도 처리하지 않은 것은 오히려 마이너스 포인트라고 하셨다. 동시성 테스트에 대한 해결방안으로 적어주신 낙관적/비관적 락킹, syncronized 에 대해 설명(RateL..