전체 글

✅ 개요오늘의 질문 조회에 대해 캐싱을 도입하게 된 계기는 다음과 같다. 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..

1️⃣ Like 테이블 데이터 정합성 문제다음의 시나리오를 가정해보자.일단 해당 시나리오는 일반적인 상황은 아니고 특정 유저의 악성적인 요청에 해당한다.User1이 1번글에 좋아요 요청을 한다.User1이 첫번째 요청과 거의 동시에 다시 1번 글에 좋아요 요청을 한다.첫번째 요청에 대해 중복체크를 조회한다.첫번째 요청에 대한 좋아요 객체를 저장하기도 전에 두번째 요청에 대한 중복체크 조회가 이루어진다. → 두 요청 모두 통과된다.첫번째 요청, 두번째 요청 모두 좋아요 객체가 저장된다.한명의 사용자는 하나의 답변에 대해 한번만 좋아요를 누를 수 있다.좋아요 갯수에 의해 인기답변이 결정되기 때문에 위 시나리오처럼 한명의 사용자가 하나의 답변에 여러 번 좋아요 누르는 것이 가능해지면 비즈니스에 있어 큰 문제가..