카드서버 리뉴얼 - 2

4/5

transactional 어노테이션을 사용하고 jmeter를 통한 부하테스트를 진행하였다.

1트랜잭션(증액요청, 감액요청)을 총 20개의 카드번호로 구성하여 각각 100번씩 수행하게하였다. 즉 4000번의 request요청이 갔다.

이 때 한 개의 카드에서 동시성 제어가 실패한 케이스가 발생했다. 확인해보니 잔액 300원을 동일하게 증감/차감 요청이 읽어가 sign값이 불일치했다. 이렇게 되면 고객은 sign값 불일치로 개발자가 db 보정을 하지 않는 한 서비스를 이용할 수 없게 된다.

transactional 어노테이션을 사용하여 모두 커버가 되었다고 생각했으나 아니었던 것이다.

의심되는 사항은 비동기 처리. (commit 됐다고 리턴 보냈는데- 사실 아직 커밋은 진행중이었으며, 다음 요청이 들어와 걔가 먼저 처리가 돼버려서 커밋 순서 역전)

이에 도움을 요청하니

1. 트랜잭션의 isolation 레벨이 exclusive 모드(serializalbe)인지
2. @.synchronized 어노테이션을 시도
3. mutex나 tryLock을 사용한 배타제어

등의 조언을 받았다.

 

@transactional connection pool

https://ksso730.github.io/2020/04/27/DB-Connection-Pool/

hikariCP 흐름

https://techblog.woowahan.com/2664/

 

https://docs.microsoft.com/ko-kr/dotnet/api/system.transactions.transactionscopeoption?view=net-6.0

sql 동시성 제어 http://www.gurubee.net/lecture/2398

 

hikariCP 데드락

https://techblog.woowahan.com/2663/