refactor: 비관적 락 적용 및 좋아요, 북마크 동시성 문제 해결

[mangsuyo]

📌 관련 이슈

피드 좋아요, 북마크 갱신 누락 동시성 문제 #372

🔥 겪은 문제

기존 코드는 (user_id, feed_id)에 대한 UNIQUE KEY 제약 조건만으로 동시성을 일부 제어하고 있었습니다.
이 방식은 단일 사용자의 중복 요청은 막을 수 있지만, 다수의 사용자가 동시에 요청할 경우 발생하는 갱신 손실 문제는 방지하지 못했습니다.

실제 멀티 스레드 테스트 환경(100 threads)에서 문제를 재현한 결과, FeedLike 레코드는 100개가 정상적으로 생성되었음에도 불구하고 Feed 엔티티의 likeCount는 10으로 기록되어, 90%의 카운트 데이터가 유실되는 데이터 불일치 현상을 확인했습니다.

👨‍🔬 다양한 동시성 제어 방식 검증

가장 적합한 해결책을 찾기 위해, 테스트 코드를 기반으로 다음과 같은 동시성 제어 기법들을 순차적으로 실험하고 장단점을 분석했습니다.

단계	적용 기술	결과 및 분석
1	트랜잭션 (SERIALIZABLE)	실패. 과도한 락 범위로 인해 수많은 데드락이 발생하여 대부분의 트랜잭션이 롤백.
2	Java synchronized	실패. 단일 JVM 기반의 테스트에서 트랜잭션의 커밋 시점과 락 해제 시점이 달라 갱신 손실이 발생함.
3	낙관적 락	부적합. 데이터 정합성은 보장되었으나, 충돌이 빈번한 '좋아요' 기능의 특성상 대부분의 요청이 예외를 발생시키며 실패함.
4	비관적 락	성공. 데이터 정합성을 완벽하게 보장하면서, 예외 발생 없이 모든 요청을 안정적으로 처리함. '좋아요'와 같이 쓰기 충돌이 빈번한 환경에 가장 적합하다고 판단.

⚒️ 작업 내용

테스트 결과, 비관적 락이 가장 안정적이고 효율적인 해결책임을 확인했습니다.
FeedRepository에 findByIdForUpdate 메소드를 추가하여, 접근 시 배타적 락을 설정하도록 구현했습니다.

비관적 락 적용 후 멀티 스레드 테스트 환경(100 threads)에서 문제를 재현한 결과 100개가 정상적으로 생성된 후
likeCount 역시 100개를 기록하며 갱신 누락 문제를 해결했습니다.

📎 커밋 범위 링크

[sangu1026]

동시성 문제 상황을 꼼꼼하게 재현하고, 다양한 접근 방식을 실험한 뒤 최적의 방법을 적용하셨네요👍
테스트 결과까지 구체적으로 공유해주셔서 이해하기 쉬웠습니다. 수고 많으셨습니다!