개발 일기 (2) 썸네일형 리스트형 🔒 Redisson 분산락으로 사용자 매칭 중복 생성 문제 해결기 🙋🏻 문제 상황: 동시에 누른 "좋아요"가 만들어낸 버그저희 서비스는 두 사용자가 서로 좋아요를 눌렀을 때 매칭을 성립시키고, 채팅방을 생성해 연결해주는 구조입니다.좋아요 요청이 들어오면 서버에서는 아래와 같은 데이터를 처리합니다:UserLike: 좋아요 상태, 매칭 여부UserJoinChatRoom: 유저-채팅방 연결ChatRoom: 채팅방 정보서버의 매칭 판별 로직은 UserLikeJpaAdapter 에서 다음과 같은 흐름을 따릅니다:기존에 좋아요한 적이 있는지 조회 (있다면 수정, 없으면 생성)좋아요 상태 업데이트상대방 차단 여부 확인상대방도 나를 좋아요했는지 확인 → 매칭 여부 결정결과를 반환더보기UserLikeJpaAdapter 의 메서드 정리 findOrCreate() - UseLike.. Redis의 원자성(Atomicity)으로 로그인 API의 동시성과 성능을 한 번에 잡다 “로그인 한 번 하는데 5초 넘게 걸려?” 개발자라면 누구나 한 번쯤 들어본 무서운 말입니다.저 역시 Datadog 대시보드를 보다가 SignIn API가 때때로 5~10초씩이나 걸리는 상황을 발견했습니다특히 에러가 나는 경우엔 대기 시간이 더 길어져, 사용자 경험이 크게 떨어졌죠. 1. 원인 추적: 그놈의 낙관적 락로그인을 찬찬히 뜯어보니,JWT 토큰의 조회/삭제/삽입 과정에서 데이터베이스를 자주 탐색하고 있었습니다 JPA에서 흔히 쓰는 낙관적 락(Optimistic Lock) 은레코드 버전 충돌이 일어날 때“에이, 설마 동시에 같은 걸 바꾸겠어?” 라는 가정 하에 동작합니다. 하지만 그 가정을 깨는 상황이 오면 ObjectOptimisticLockingFailureException 이라는 예외가 발생.. 이전 1 다음
