Refactor: 좋아요 요청 동시성 해결 및 배치 처리 로직 개선

[JongWook6]

✅ PR 올리기 전에

• dev에서 pull 받았나요?
• merge conflict 발생 시, 해결하고 올리셨나요?
• 자신이 작업한 changes만 존재하나요?
• 작업 중 DB 변경이 발생했나요?

🐶 구현한 기능

• 좋아요 요청 동시성 문제 해결
• 배치 처리 로직 개선

🔎 작업 내용

📍좋아요 요청 동시성 문제 해결

• (문제 상황) 기존의 로직은 서버 인스턴스가 여러 개일 때에 대한 고려가 없었음
• (예시) 1, 2, 3번 게시글에 대한 좋아요 요청이 레디스에 저장됐을 때, 서버 인스턴스 A, B에서 연속적으로 배치 스케줄링이 실행될 경우 두 인스턴스 모두 1, 2, 3번 게시글에 대한 요청이 있었다고 인식하고 DB에 2개씩 저장되는 문제가 발생
• (해결 과정) Redisson의 분산 락(Distributed Lock) 을 활용. 기본 Redis에서도 분산 락 기능은 제공하지만 직접 락 획득, 해제, 갱신 등의 과정을 구현해야 하기에 기본적인 추상화, 예외 처리가 구현된 Redisson을 선택했습니다. 관련해서 의존성과 설정 클래스를 추가했습니다.

📍배치 처리 트랜잭션 단위 변경

• (문제 상황) 기존 로직은 모든 좋아요 및 취소 요청에 대해 하나의 트랜잭션으로 다루었기에 롤백되는 범위가 너무 큼
• (예시) 10개의 요청 중 9개의 요청을 잘 처리하더라도 마지막 1개의 요청 처리에 오류가 발생하면 모두 롤백되는 문제
• (해결 과정) 따라서 트랜잭션 단위를 article 단위로 나누고, @transactional은 AOP를 기반으로 동작하기에 별도의 클래스에서 DB에 반영하는 메서드를 다시 작성했습니다.

📍배치 처리 실패 시 재시도 가능하도록 개선

• (문제 상황) 배치 프로세서가 redis에 저장된 요청을 가져오면서 동시에 모두 비워버리기 때문에 배치 처리 중 오류가 발생하면 재시도가 불가능
• (해결 과정) 이를 개선하기 위해 요청 조회 & 삭제를 한 번에 처리하던 메서드를 분리했습니다. 배치 처리 전 저장된 요청을 가져오고, 트랜잭션이 정상적으로 완료되고 커밋됐을 때만 해당 요청을 삭제합니다. 따라서 요청 처리가 실패했을 경우 redis에 그대로 남아있기 때문에 다음 스케줄링 때 재시도할 수 있습니다.

📍인덱스 추가

• 게시글, 댓글, 게시글 이미지, 게시글 좋아요 테이블에 필터 조건, 정렬 조건으로 자주 사용되는 컬럼에 인덱스 추가

[eonwy]

redis를 더 안전하게 활용하게 된 것 같아요!

[ash-be]

좋아요 기능 검색하면 항상 동시성 문제가 딸려나오던데, 레디손으로 푸셨군요!
덕분에 코드 열심히 뜯어보고 공부가 많이 되었습니다.!