서론앞서 트랜잭션과 격리 수준, DB가 보장하는 동시성 제어를 정리해 보았다. 이번에는 실제 주문 로직에 어떻게 적용했는지를 정리해보고자 한다. 이번 주차 구현에서는 DB 레벨의 락 전략 학습이 목표였기 때문에 Redis와 같은 분산락은 고려하지 않고 낙관적 락과 비관적 락을 먼저 도입해 보기로 했다. 왜 락 전략이 필요하지?InnoDB의 MVCC와 Next-Key Lock 덕분에 기본적인 읽기 일관성이나 Phantom Read 방지는 잘 되지만 도메인 규칙까지 완전히 보장하기에는 부족하다고 느꼈다. 따라서 락 전략을 추가해 보기로 했다. 낙관적 락 vs 비관적 락두 방식을 간단하게 비교하면 아래와 같다.구분낙관적 락 (Optimistic Lock)비관적 락 (Pessimistic Lock)방식버전 ..

TL;DRInnoDB는 MVCC + Undo Log로 스냅샷 읽기를 제공하고, Next-Key Lock으로 신규 레코드 삽입까지 차단하여 Repeatable Read에서도 Phantom Read를 방지한다. 서론앞서 트랜잭션과 격리 수준을 살펴보면서 MySQL의 InnoDB의 기본 격리 수준이 Repeatable Read이고, 대부분의 동시성 문제를 방지할 수 있다고 확인했다. 특히 일반적으로 Repeatable Read에서 발생할 수 있는 Phantom Read 현상도 InnoDB에서는 방지된다고 한다. 어떻게 InnoDB는 내부적으로 그런 격리성을 보장하는 걸까? 그리고 다른 DB와는 어떻게 다를까? MVCC(Multi Version Concurrency Control)MySQL 이라고 해서 항상..

TL;DR트랜잭션은 작업을 모두 성공하거나 모두 실패시키는 작업 단위이며, ACID 속성으로 무결성을 보장한다.격리성(Isolation)은 동시에 실행되는 트랜잭션이 서로 간섭하지 않도록 하는 성질로 격리 수준에 따라 정합성과 성능이 달라진다.MySQL InnoDB는 기본적으로 `Repeatable Read` 를 사용해 대부분의 정합성 문제를 막지만, 경합이 심한 자원은 추가 락이나 더 높은 격리 수준이 필요할 수 있다. 서론이번 프로젝트에서 주문 로직을 구현하던 중 멱등성에 대해 고민하다가 예상치 못한 동시성 문제를 마주하게 되었다.- 사용자가 발급받은 쿠폰은 단 한 번만 사용할 수 있어야한다.- 재고 차감은 동시에 여러 사용자가 주문하더라도 일관성을 유지해야한다.애플리케이션 로직으로 최대한 방어하더..