보통 이런 접수는 접수날짜+접수상태로 인원수 카운팅함
(결제대기, 취소, 완료 기타 등)
이번에 mynb접수에서 홈페이지 접수로 바꾸면서
로직 수정했나본데 접수완료처리하는 로직이나
인원수 카운팅하는 로직이 꼬인거같음
의심스러운건 접수날짜인데
이게 개발 환경, 언어, 접속 브라우저에따라서 똑같은 시간을 01시, 1시, 13시, pm1시 등 제각각으로 가져옴
아마 시간 데이터를 잘못 조인걸어서
카운팅을 잘못하면서 계속 접수 받은듯?
담당자는 이 상황 모르고 접수 완료상태 숫자만 보고 다 찻다고 생각하고 마감 스토리 올린거고
로직 수정하려면 서버를 재기동해야 반영되고 테스트없이 재기동 하기에는 사이드이펙트가 부담되니 재기동 필요없는 화면단 스크립트로 임시로 페이지 막아둔듯?
아니면 보통 결제 취소나 변경 결제 후 어떤 액션으로 칼럼 값이 바뀌었는데도 집계 통계 쿼리는 그걸 반영 못하는 쓰레기 쿼리라 잘못 집계된 걸수도ㅋㅋ
ㅇㅇ 카운트 쿼리문제가 유력함
작년 여의도할때도 마감이라고 해놓고 앱으로 계속 신청받아졌었음
그럼 11시에 신청된 사람은 뭔 상황임?
준비생이 본 입장은 아래와 같음이넘은 토스페이먼츠 API 사용함1. 사용자가 "결제하기" 버튼을 누르면, 먼저 데이터베이스에서 남아있는 수량을 확인2. 남아있는 수량이 있으면 토스페이먼츠 API에 결제 요청을 보냄3. 결제가 정상적으로 완료되면, 사용자에게 결제 성공 페이지로 리다이렉트BUT 여기서 문제요청량이 많아지는 경우, 서버가 토스페이먼츠 API의 응답을 정상적으로 처리하지 못하는 상황이 발생이로 인해 결제는 완료되었지만, 사용자가 결제 완료 메시지(예: 카카오톡 알림)를 받지 못하거나 성공 페이지로 리다이렉트되지 않는 문제가 발생
그런거 다 필요없고 카운팅 쿼리 이슈가 유력함 과거에 대학전산실있어봐서 수강신청기간에 비슷한 경험있음
그냥 요청량을 분산처리 할 수 있는 방법을 쓰면 해결 가능 나같으면 카프카 사용함
카프카나 레디스 이런 문제가 아니라 인원수 카운트 쿼리 문제 같아보였음
나는 아닌 것 같음 1시간동안 4번 결제 성공함 즉 분명 결제전에 남아있는 티켓개수가 있는지 확인하는 로직있는거 확인하고 결제 요청을 토스 페이먼츠로 요청함 but 결제 성공했지만 성공 페이지로 리다이렉트 성공해야 티켓 개수를 차감하는데 요청량이 많아서 서버가 결제완료한뒤에 완료했다는 요청을 못받아서 티켓 개수 차감을 못함 이러한 상황이 반복되니 결제만 성공한 사람이 넘쳐남
그럼 갤럼맘대로라면 담당자는 뭘보고 마감이라고함? 타겟개수를 봣을건데 타겟개수가 마감인데 추가로 접수는 어케된거? 쿼리 문제라니까
티켓 개수가 마감이된것은 결제가 성공하고 요청이 서버에 닿으면 정상적으로 티겟개수가 차감이되니까 정상적으로 서버에 요청이 도달한 것만 카운팅을하니까 그러징 서버가 뻑나지 않은이상 일부 요청은 성공적으로 처리가되니까 ok??? 즉 지금 이미 티켓개수만큼 다찼지만 내가말한 이유때문에 결제까지 완료한 사람이 훨씬 많음
몬소린지 모르겠네 티켓개수가 차감됐으면 결제전 남은 티켓개수 확인 로직에서 걸러져야지... 난 비슷한 경험이있기때문에 카운팅 쿼리 문제라고 생각함 내가 이해는 못했지만 갤러의 말이 맞을수도있음
쿼리가 문제였다면 10시 1분에 결제한 사람들이 바로 2분에 결제 취소되는 일을 설명할 수가 없음
그건 또 뭔소리야 동시에 너무 많이 요청하면 인덱스 꼬이면 pk에러 나면서 그런건 빈번하게 일어남
결제 취소되는건 내가보낸 데이터랑 결제사쪽에서 보낸데이터랑 맞춰보고 다르면 자동 취소하는데 동시에 너무 많은 요청들어오면 둘중하나의 데이터가 꼬이는건 자주있음
경력이직 준비생인지 신입준비생인지 모르겠지만 테스트할때는 부하테스트 꼭 해봐 난 초당 3-400건정도 부하주는데 db락 잡는 타이밍도 잘 잡아야됨