본문 바로가기

전체 글

 (16)
🔒 Redisson 분산락으로 사용자 매칭 중복 생성 문제 해결기 🙋🏻 문제 상황: 동시에 누른 "좋아요"가 만들어낸 버그저희 서비스는 두 사용자가 서로 좋아요를 눌렀을 때 매칭을 성립시키고, 채팅방을 생성해 연결해주는 구조입니다.좋아요 요청이 들어오면 서버에서는 아래와 같은 데이터를 처리합니다:UserLike: 좋아요 상태, 매칭 여부UserJoinChatRoom: 유저-채팅방 연결ChatRoom: 채팅방 정보서버의 매칭 판별 로직은 UserLikeJpaAdapter 에서 다음과 같은 흐름을 따릅니다:기존에 좋아요한 적이 있는지 조회 (있다면 수정, 없으면 생성)좋아요 상태 업데이트상대방 차단 여부 확인상대방도 나를 좋아요했는지 확인 → 매칭 여부 결정결과를 반환더보기UserLikeJpaAdapter 의 메서드 정리 findOrCreate() - UseLike..
Redis의 원자성(Atomicity)으로 로그인 API의 동시성과 성능을 한 번에 잡다 “로그인 한 번 하는데 5초 넘게 걸려?” 개발자라면 누구나 한 번쯤 들어본 무서운 말입니다.저 역시 Datadog 대시보드를 보다가 SignIn API가 때때로 5~10초씩이나 걸리는 상황을 발견했습니다특히 에러가 나는 경우엔 대기 시간이 더 길어져, 사용자 경험이 크게 떨어졌죠. 1. 원인 추적: 그놈의 낙관적 락로그인을 찬찬히 뜯어보니,JWT 토큰의 조회/삭제/삽입 과정에서 데이터베이스를 자주 탐색하고 있었습니다 JPA에서 흔히 쓰는 낙관적 락(Optimistic Lock) 은레코드 버전 충돌이 일어날 때“에이, 설마 동시에 같은 걸 바꾸겠어?” 라는 가정 하에 동작합니다. 하지만 그 가정을 깨는 상황이 오면 ObjectOptimisticLockingFailureException 이라는 예외가 발생..
[Kafka] Listener 기본 설정 (6) 이번에 카프카를 구현하면서 오랜만에 막연함을 느꼈던 것 같다. 구현을 하고, 원리 같은 걸 공부해보기는 했는데 붕 뜬 지식을 잡으려 손을 뻗는 기분이었다.왜 그런 기분을 느낄까 생각해 보면 답은 하나밖에 나오지 않았다.잘 모르기 때문에.나름대로 정리도 해보고 구현도 해봤는데 왜 잘 모를까.여러 가지 블로그를 기반으로 공부하다 보니까 카프카에 대해서 중구난방으로 공부하게 된 것 같았다.  내가 헷갈렸던 내용은 아래와 같다.BatchListner와 RecordListenerBatchListener를 ‘한 번에 여러 레코드를 처리한다’고 정리된 글을 읽고 BatchListener는 병렬처리를 하는 리스너라고 생각을 했다.하지만 코드를 보다보면 Concurrent… 가 붙은 용어( ex. ConcurrentKa..

티스토리툴바