일단 주문 생성 트랜잭션이
사전 정보 검증 > 주문 생성 > 계산 > 주문 저장 > 원장 저장 > 반환 의 순서인데
db에 유니크 걸어둬서 주문 저장하는 시점에서 예외 터지고 롤백하는데
결국 이말은 10개가 동시 요청들어오면 계산 까지는 전부 하고 주문 저장에서 롤백되는거잖아 아무리봐도 이건 리소스 낭비인데
그렇다고 사전정보 검증안하고 먼저 주문을 저장할순 없는데
보통 어떻게 해결함? 아예 테이블에 멱등성키 만들어두고 그걸로 그냥 검증하나 제일 앞에서?
동일한 사람이 중복해서 주문을 하는 경우를 말하는거야? - dc App
이거면 뭐 분산락같은걸로 동시요청 막는게 ㄱㅊ지않나 - dc App
ㅇㅇ 맞아 동일한 사람이 중복해서 주문을 한다면
네임드락or레디스써도 되고, pending상태의 레코드를 처음부터 삽입하고 스케줄러에 위임해도 될듯
네임드락이 뭔지 찾아보고왔네 이것도 근데 비슷하게 db커넥션이 유지되는거니까 한번 봐야겠다.
해당 댓글은 삭제되었습니다.
아 트랜잭션 범위를 줄..여야 하나? 해봐야 사전정보 검증 을 분리시키면될거는 같은데 유니크가 롤백된다는게 아니구 그 유니크키가 걸려있으니까 db세이브 시점에서야 race경합이 해소가 되잖아. 내말은 db저장하는 시점까지 검증 > 주문생성 > 계산 의 프로세스를 타는게 리소스 소모라는거지 결국 제일 앞에서 뭐 멱등성 키라도 저장해서 검증한다면 거기서 경합 다 풀리는거지않나 해서...
@공채는코테다 아 사전검증은 왜 넣은거냐면 이제 거래소 주문할떄 주문한 사용자가 맞는지 자산이랑 시장이 올바른지 검증하는거지.
@공채는코테다 감사감사 트랜잭션 범위가 좀 크긴한것도 같네. 어짜피 사전검증만 분할되도 많이 해소될거같긴하네
연산이 cpu만 먹는다는 가정 하에 상관없음 그 연산 하는동안 디비커넥션 물고 있는게 더 손해임
연산이 비싼 연산이면 윗댓 말대로 레디스 락을 쓰던 네임드락을 쓰던 따닥 막으면 될듯
아 그렇네 flush라서 커넥션 계속 가지고 있구나
계산까지 트랜잭션에 포함시킬필요없는거 아닌가 로직을 정확히 몰라서 맞는진모르겠는데 - dc App
아 저 계산이 실제 금액 계산이 아니고 거래소라서 available -> lock 을 해야할 금액만 계산하는거라서
멱등성키 만들고 맨 앞에서 먼저 db에 멱등성키로 검증 하고 들어가 트랜잭션 걸지말고 애초에 트랜잭션은 주문 저장 쪽에서만 걸면되짐 머하러 다 걸음?
검증이 주문을 걸수 있는 상태인지의 검증이라 트랜잭션 안에서 해야할거같아서
@1일1행 생각해보니까 검증 자체를 분리해도 상관은 없겠네 ㄱㅅㄱㅅ
@1일1행 트랜잭션 개념을 다시 찾아보는게 좋을듯 보통 db에 관련되어 있지 않은 계산은 넣지않음
@백갤러1(122.37) ㄱㅅㄱㅅ 지금은 db도 침범해서 이거를 좀 분리해서 어떻게 잘 해봐야겠다.
@1일1행 주문쪽이면 비관적락 거는것도 괜찮을듯
@백갤러1(122.37) 비관적락 나쁘지 않긴함
락쓰셈 - dc App
idempotency
커넥션 유지 오래하는게 문제인지 cpu 쓰는게 문제인지 문제를 정의하고 해결 - dc App