데브코스/실습 & 프로젝트

✅ 쿼리 최적화의 필요성쿼리 최적화가 필요하다고 생각한 API는 두 가지이다. 1️⃣ 답변 목록 조회 API1. 답변 리스트 페이징해서 조회더보기User answerAuthor = userRepository.findById(answer.getUserId()) .orElseThrow(() -> UserNotFoundException.EXCEPTION);SELECT answer.answer_id, answer.content, answer.created_at, answer.like_count, answer.question_id, answer.url, answer.user_id, answer.visibilityFROM answerJO..

✅ 개요오늘의 질문 조회에 대해 캐싱을 도입하게 된 계기는 다음과 같다. 1️⃣ 호출 빈도가 높음현재 프로젝트에서 오늘의 질문 조회 API는 매우 잦게 호출되는 API이다.다음과 같이 메인페이지에서 답변을 볼 때 항상 노출되게 된다.2️⃣ 수정 빈도가 낮음현재 프로젝트에서 질문은 하루에 한번 변경되기 때문에 변경빈도가 매우 낮다. ✅ 구현캐싱은 Redis를 활용하기로 결정했다.현재 프로젝트에서 Redis를 사용하고 있고 다른 팀원분께서 Redis 캐싱에 대한 인터페이스를 구현해두신게 있어 간편하게 구현이 가능할 것 같아서 Redis를 선택했다. 1️⃣ 캐싱 전 코드/** * 카테고리로 질문 조회 */public QuestionFindServiceResponse findQuestionByCategoryId..

현재 포스트는 해당 포스트에서 이어지는 내용입니다. [최종 프로젝트] 좋아요 API 동시성 이슈 해결 - 1. Like 테이블 데이터 정합성 문제1️⃣ Like 테이블 데이터 정합성 문제다음의 시나리오를 가정해보자.일단 해당 시나리오는 일반적인 상황은 아니고 특정 유저의 악성적인 요청에 해당한다.User1이 1번글에 좋아요 요청을 한다.Ujaehee1007.tistory.com   ✅ Redisson 분산 락으로 해결하기@Lock를 활용한 비관적 락 적용은 Spring Data Jpa를 사용하는 프로젝트에서 매우 간편한 솔루션이 되지만 큰 단점들이 있다.👿 단점1: 높은 병목 가능성@Lock 어노테이션은 실제 데이터베이스 내부 자원에 락을 설정한다. 데이터베이스는 그 락을 관리하기 위해 트랜잭션과 연결..

✅ Answer 테이블 데이터 정합성 문제다음의 시나리오를 보자.사용자1, 사용자2가 동시에 1번글에 좋아요 요청을 한다.(간발의 차이로 1번이 빨랐다고 가정)두 요청 모두 수정을 위해 좋아요가 0인 상태에서 Answer 정보가 조회된다.사용자1의 요청에 의해 좋아요가 1 증가한다. (0 ➡️ 1)사용자2의 요청에 의해 좋아요가 1 증가한다. (0 ➡️ 1)분명 요청은 두 번인데 좋아요는 1만 증가하는 상황이 발생했다.이처럼 공유데이터에 동시에 접근하려고 하면 경합 상태(Race Condition)가 발생해 데이터 정합성에 문제가 발생한다.실제로 그런지 테스트 코드를 통해 확인해보자.@Testpublic void 답변_좋아요_추가_기본() throws Exception { // given in..