No video
[개발일기] 온라인 결제 프로세스에 대한 이야기 (동시성 제어, dead lock, wait timeout, isolation level, db replication)
Рет қаралды 1,391
Күн бұрын온라인 결제 프로세스에 대한 이야기
- 동시성 제어
- dead lock
- wait timeout
- db replication
- isolation level
- 재고 관리
- transaction
- rollback
#팔복소프트 #palboksoft #예천 #경북 #쇼핑몰 #온라인결제 #결제시스템 #개발이야기 #개발자
@divakukulza 2 күн бұрын
말투 너무 재미있우요 ㅋㅋ
@user-ny6pt8qf6s 2 ай бұрын
주니어 입장에서 과정 이해가 쏙쏙 되네요 ㅎㅎ
@argenyoo9456 Ай бұрын
좋은 영상 감사합니다!
@user-we5xx1tk9f Жыл бұрын
좋은 영상 감사드립니다~~
@user-pv6qb4ur9y 11 ай бұрын
안녕하세요!!! 지금 결제 주문 프로세스를 준비하고 있는 중에 영상을 보고 여쭤볼게 있어서 댓글 남기게 되었습니다!! (일단 좋은 영상 너무 감사합니다!!! 노래 커버도 들었지요 하하) 지금 밑에 댓글에 간단한 코드로써도 볼 수 있듯이 팔복님께서 결제요청-승인 과정을 트랜잭션 시작 전으로 빼셨잖아요? 그렇다면 결제 요청 전에 주문 테이블에 주문관련 데이터 생성하는 작업 및 메뉴 수량 차감, 유저 쿠폰 삭제, 포인트 차감 등을 수행하지 않고 결제가 다 승인된 후에 트랜잭션으로써 수행하신다는 것 같은데, 이렇게 되면 데이터 정합성 체킹은 어떻게 하는 것일까요? 구매자가 혹여 브라우저 접근등으로 쿠폰, 포인트 및 총 결제금액을 조작할 수도 있다고 들었습니다. 이런 경우 결제 승인 전에 정합성 체킹을 해야할 거 같다는 생각이 들기도 한데 이런 프로세스는 어떤가 한번 여쭤봅니다!!! 참고로 전 토스페이먼츠를 연동하게 됩니다! 제가 생각하고 있는 프로세스는 1. 트랜잭션 시작 2. 클라이언트가 결제 요청버튼을 누르면 (즉, 토스페이먼츠 결제모듈로 진입할시에) 주문 생성 및 쿠폰, 포인트, 메뉴수량에 대한 작업 수행 3. 결제 요청 - 인증 수행 (아직 승인은 처리 전) 4. 결제 승인 전 결제 성공을 통해 pg사에서 받아온 (토스페이먼츠에서 받아온) 결제 데이터들을 토대로 앞서 2번과정에서 수행한 디비에 넣어진 데이터들과 비교 검증 작업 (데이터 정합성 체킹) 5. 이것이 잘 해결되면 결제 승인 6. 만약 데이터 체킹 작업에서 맞지 않는 경우 발생 시 롤백 7. 트랜잭션 종료 요렇게 입니다!!!! 이렇게 하려고 하니 영상에서 말씀하신것처럼 뭔가 트랜잭션 내부에서 많은 것을 다루고 있어 타임아웃등의 이슈가 발생할 수 있을거 같기도 하고... 이런것들이 고민이 되어서 질문을 올리게 되었습니다!!! 장문이지만 읽어주신다면 감사하겠습니다!!! 아 그리고 저는 배민?? 과같은 서비스 처럼 유저의 앱 - 가게 포스기 이렇게 두 가지로 분리되어있는 구조입니다. 그래서 주문 취소에 대해서 유저가 직접 주문 취소를 하는 경우도 있겠지만 만약 가게 사장님이 주문접수를 하지 않았을 시 취소가 되게 해야할 것 같기도 합니다!! 이 과정은 트랜잭션 이후의 과정으로 생각하려고 하고 있는데 혹시 요런 점에 대해서 조언해주실 부분이 있으시다면 따수운 말씀 부탁드립니다!!! ㅎㅎ 감사합니다!!!
@kimpalbok 11 ай бұрын
1. [프론트엔드] 결제 상품 선택 및 주문서 생성 요청 2. [백엔드] 임시주문서 또는 대기상태의 주문서 생성 (설계하신 내용에 따라 적절히...) 3. [프론트엔드] 토스페이먼츠 위젯 -> 결제 4. [프론트엔드] 백엔드로 confirm 요청 5. [백엔드] confirm 시작 // a = 토스페이먼츠 paymentKey로 결제 조회 api.tosspayments.com/v1/payments/${paymentKey} // b = 내 주문서 정보 // a 와 b 비교 (orderId, 결제금액, 주문서 존재여부 등등 비교) // 재고 확인 // c = 토스패이먼츠 confirm() api.tosspayments.com/v1/payments/confirm 트랜젝션 [시작] try { // 주문서 생성 또는 주문서 업데이트 (설계하신 내용에 따라 적절히...) // 결제 정보 저장 // 재고 차감 (** 중요 [영상에서 표현한 쿼리문 참고] **) // 쿠폰 처리 // 포인트 처리 } catch (error) { // error 발생시 토스페이 결제 취소 api.tosspayments.com/v1/payments/${paymentKey}/cancel } finally { // 트랜젝션 release } 트랜젝션 [끝] // 결제완료 알림 및 푸시 보내기 // 등등 6. [프론트엔드] 결제 완료 또는 실패 페이지 제가 영상에 담은 내용은 "5. [백엔드] confirm" 부분입니다~ 쿠폰과 포인트 처리도 간단하진 않았던걸로 기억하네요.. 쿠폰과 포인트 처리할때도 가능하면 update 발생하지 않고 insert만 발생되도록 하는 설계가 필요하지 않았나요? ㅎ
@kimpalbok 11 ай бұрын
그리고 토스페이먼츠 결제 완료시 webhook 을 받아 따로 저장해두세요~ 그리고 배치를 돌려 누락 주문서 체크를 꼭 하세요~ 결제는 완료 되었으나 문제가 되는 주문서가 발생하진 않았는지 2중으로 모니터링 하는 것입니다. 도움이 되셨으면 좋겠습니다~
@kimpalbok 11 ай бұрын
cluster-taek.tistory.com/entry/%EC%9E%AC%EA%B3%A0-%EC%A3%BC%EB%AC%B8-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%97%90%EC%84%9C%EC%9D%98-%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%A0%9C%EC%96%B4 저는 이 블로그를 통해 재고차감 동시성 이슈를 해결 했었습니다~
@user-pv6qb4ur9y 11 ай бұрын
오…! 지금부터 읽어보겟습니다!!!! 자세한 답변 너무 감사합니다 ㅠㅠㅠ 혹시 죄송하지만 배치를 돌려 다시한번 주문을 검증하는 작업은 어느 시점에서 수행되어야 할까요? 웹훅은 토스페이먼츠의 “요청 - 인증 - 승인”중 인증과 승인 사이에 이루어진다고 인지하고 있습니다. 그러면 api폴링.? 을 또한 배치 요청부는 어떤시점에 수행하는 작업인지 궁금하네요!! (아 참고로 저는 nestjs+typeorm을 사용중입니다!! 예전에 제가 선생님 네스트 sentry영상을 봣었던 기억에 혹시 nest관련 질문을 드리자면 위의 언급하신 주문 검증 배치 프로세스의 경우는 어떻게 수행하면 좋을까요..? 생각나는건 @Cron을 사용한 task scheduling밖에 안떠오르네욥.. ㅎ
@kimpalbok 11 ай бұрын
@@user-pv6qb4ur9y 새로운 프로젝트 만드셔서 nestjs + node-schedule 를 사용해 스케줄러 전용으로 따로 운영하는 것도 좋을 것 같아요~ 웹훅은 결제완료되자 마자 거의 바로 날아오니, 바로 검증할 순 없구요. 텀을 쫌 주고 (10분정도?) 누락 주문서 검사 하는게 좋을 것 같아요~
Дима Масленников
Рет қаралды 9 МЛН