비관적 락(Pessimistic Lock) 도입

🛠 해결 방법: 비관적 락(Pessimistic Lock) 도입

 

비관적 락 도입

🔍 문제 해결 방향

1. 트랜잭션 (@Transactional) 으로 송금 단위 작업을 하나의 논리적 처리 단위로 묶었고
2. SELECT ... FOR UPDATE (비관적 락) 을 통해
   같은 송신자 계좌에 여러 쓰레드가 동시에 접근할 때 락을 걸어서 충돌을 방지했어.
3. 테스트에서도 10개의 송금 요청을 동시에 날렸을 때도
   • 데이터 정합성이 깨지지 않았고
   • 데드락도 안 생기고
   • 송신자 잔고: 500 / 수신자 잔고: 500 으로 정확하게 처리됐어.

---

🔒 비관적 락 적용 흐름

1. @Lock(LockModeType.PESSIMISTIC_WRITE)를 통해 송신자, 수신자 계좌 row에 락을 건다.
2. 트랜잭션 내에서 포인트 차감 및 적립을 수행한다.
3. 트랜잭션이 끝나면 락이 해제된다.

💡 도입 후 개선점

 

항목	Before	After
데이터 정합성	충돌 및 데드락 발생	안정적 처리
에러 발생률	Deadlock, NoSuchElementException	없음
동시성 처리 전략	미비	명시적 비관적 락 도입

---

👀 그래서 이건 어디에 쓰이냐?

• 포인트 송금 / 은행 계좌 잔고 / 재고 차감 / 쿠폰 사용 등
• “하나만 있어야 하는 자원”을 실시간으로 정확하게 처리해야 할 때 매우 중요해

 

📌 추후 계획

• 트래픽 증가 시 낙관적 락 + 재시도로 전환 고려
• 이벤트 기반 처리 도입: Kafka + Redis Lock 조합 설계
• 조회 성능 향상을 위한 CQRS 구조 분리