이번 글 요약Redis로 분산 락을 직접 만들어 붙였는데, 처음엔 재고 100개에 최대 300명이 샀다. 락을 DB에 확정 저장(커밋)하기 전에 풀고 있었다.커밋이 끝난 뒤에 락을 풀도록 고치자 정확히 100명만 사졌다.그런데 주문이 몰리자 Redis 락은 비관적 락의 절반밖에 처리하지 못했고, 상관없는 상품 조회까지 4.5초로 느려졌다. 서버를 2대로 늘려도 같았다.방식재고 100개에 300명주문이 초당 600건 몰릴 때 처리량그때 다른 상품 조회 응답Redis 락 (처음 버전)최대 300명 성공 ❌——Redis 락 (고친 버전)100명 성공 ✅초당 약 310건 ❌4.5초 ❌비관적 락100명 성공 ✅초당 600건 ✅0.01초 ✅원자적 UPDATE100명 성공 ✅초당 600건 ✅0.01초 ✅먼저 알아 둘..

이번 글 요약진단편에서 찾은 문제 2(재고 100개에 300명이 삼) 를 고친다.방식재고 100개, 300명인기 상품 초당 300건락 없음300명 성공, 재고 65 남음 ❌p95 0.32초, 판매 기록 1,105건 사라짐 ❌비관적 락100명 성공, 재고 0 ✅p95 0.31초 ✅낙관적 락100명 성공, 재고 0 ✅p95 12.3초, 실패 292건 ❌원자적 UPDATE100명 성공, 재고 0 ✅p95 0.31초 ✅셋 다 재고는 맞췄다. 차이는 요청이 한 상품에 몰릴 때 났다.트랜잭션 분리 후 재측정지난 글(#02)에서 외부 결제 호출을 트랜잭션 밖으로 빼서 응답 시간을 38초에서 0.3초로 줄였다. 그때 재고 손실도 7,115건에서 24건으로 줄어서, 솔직히 "이 정도면 거의 된 거 아닌가?" 싶었다.그래..

이번 글 요약지난 글에서 찾은 문제 1(너무 느리고, 초당 31건밖에 처리 못 함) 을 고친다.시도결과커넥션 풀 10개 → 30개통과했다. 그런데 PG가 1초로 느려지자 p95 42초로 다시 무너졌다외부 결제 호출을 트랜잭션 밖으로풀 10개 그대로 p95 38초 → 0.33초. PG가 1초로 느려져도 버틴다핵심은 하나다. 커넥션을 늘리는 것보다, 커넥션을 쥐고 있는 시간을 줄이는 게 먼저다.지난 글 요약: 문제 1주문 한 건을 처리하는 동안, 외부 PG사의 결제 응답(약 0.3초)을 기다리면서도 DB 커넥션을 계속 쥐고 있었다.@Transactional ← 여기서 커넥션을 빌림 재고 차감 주문 저장 PG 결제 요청 ... 0.3초 대기 ... ← 커넥션을 쥔 채로 기다림 결제 저장 ..

이번 글 요약타임딜 주문 API를 만들고 K6로 부하를 걸어봤다. 에러는 하나도 없었는데, 실제로는 세 가지가 망가져 있었다. 문제관측한 수치1너무 느리고, 초당 처리량이 낮다p95 38초, 최대 약 31 TPS2재고가 맞지 않는다재고 100개에 300명 전원 구매 성공, 남은 재고 70개3사용자가 포기한 주문도 결제된다응답을 못 받은 요청 550건이 전부 결제 완료이번 글에서는 고치지 않는다. 무엇이, 왜 망가졌는지만 정리하고, 다음 글부터 하나씩 고친다.무엇을 만들었나타임딜 상품(재고 100개)을 오픈 시간에 많은 사람이 동시에 주문하는 상황을 가정했다. 주문 한 건의 흐름은 이렇다.POST /api/orders (하나의 @Transactional 안에서) 1. 재고 조회 → 재고 차감 2. 주..

문제진열된 보석들 중 모든 종류의 보석을 적어도 하나 이상 포함하는 가장 짧은 구간을 찾아야 한다.조건은 다음과 같다:보석의 진열 순서가 담긴 문자열 배열 gems가 주어진다.진열된 보석들을 연속적으로 선택한 구간 중, 모든 보석 종류를 한 번 이상 포함하는 가장 짧은 구간의 시작과 끝 인덱스를 반환한다.정답이 여러 개인 경우, 시작 인덱스가 가장 작은 구간을 반환한다.풀이 방법풀이 시간 : 1시간풀이 방법 : 투포인터 + 해시맵 (슬라이딩 윈도우) 반환 타입을 보자마자 이건 투포인터구나! 라는 생각을 했다.그리고 문제에 나와있는대로 모든 종류를 포함해야 한다는 조건때문에 Set과 HashMap을 이용해 중복에 대한 처리를 진행하거나, 갯수에 대한 처리를 진행할 수 있을 것 같다는 생각을 하고 들어갔다...

문제트럭 여러 대가 순서대로 다리를 지나가야 한다. 단, 다리는 bridge_length 만큼의 길이를 가지며, 동시에 올라갈 수 있는 트럭의 무게 합은 weight를 넘지 않아야 한다. 트럭은 1초에 1만큼 이동, 다리에 올라간 순서대로 움직인다. 모든 트럭이 다리를 건너는 데 걸리는 최소 시간을 구해야한다.풀이방법풀이 시간 : 30분풀이 방법 : 시뮬레이션 + 큐(Queue) 처음에는 단순히 다리 길이나 무게 제한만 고려해서 트럭을 올릴 수 있는지 판단하면 된다고 생각했다.하지만 다리 위에서 트럭이 동시에 이동하고, 무게 제한도 유지하며 매 초마다 트럭이 한칸씩 이동한다는 점에서 단순 조건문으로는 해결할 수 없었따. 예를 들어,더보기bridge_length = 2 weight = 10 truc..