분산락과 낙관적 락을 사용한 데이터 정합성 지키기보상 트랜잭션을 사용한 데이터 정합성 유지하기 블로그 글에서 주문 비즈니스 로직에서 분산 트랜잭션을 처리 시스템을 구축했다.특히 상품 서비스에서 재고를 관리하고 있으며, 다수의 사용자가 동시에 한정 수량의 상품을 구매할 경우 UPDATE inventory SET quantity = quantity - 1와 같은 단순 쿼리만으로는 경쟁 조건(Race Condition)이 발생해 데이터 정합성이 쉽게 깨질 수 있다. 따라서 이커머스에서 재고의 정확성은 곧 서비스 신뢰도와 직결되므로, 정합성을 보장하기 위한 아키텍처 설계와 동시에 제어 전략이 필수적이다.이를 해결하기 위해 상품 서비스에서 일반적으로 비관적 락(Pessimistic Lock)과 낙관적 락(Opti..
분산 락 사용 시 상위 트랜잭션이 있으면 안되는 이유 주문 기능 중 재고 차감을 데이터 정합성을 위해 비관적 락으로 먼저 구현하고, 다음으로 Redisson을 사용하여 분산 락으로 구현하려고 했지만 주문 트랜잭션에서 상위 트랜잭션이 있는 경우에는 적용하지 못해 그 이유에 대해 작성해보고자 한다. Redisson을 사용한 분산 락 Redisson은 pub/sub 기반으로 Lock 구현을 제공한다. 채널을 하나 만들고 Lock을 점유중인 스레드가 Lock을 획득하려고 하는 스레드들에게 해제를 알려주고 안내를 받은 스레드가 Lock 획득 시도하는 방식으로 스핀락을 통해 계속해서 락을 획득할 수 있는지 요청해야 하는 Lettuce의 경우보다 부하를 덜 줄 수 있다. boolean tryLock(long wait..
- Total
- Today
- Yesterday
- spring session
- 분산 락
- sql
- postgresql
- 비관적 락
- mdcfilter
- jvm 메모리 구조
- 넥스트스탭
- TDD
- nginx
- 트랜잭션
- 구름톤 챌린지
- Java
- Redisson
- mysql
- 낙관적 락
- redis session
- EKS
- socket
- Kafka
- Synchronized
- annotation
- transaction
- 카프카
- NeXTSTEP
- spring webflux
- 구름톤챌린지
- pessimistic lock
- nginx configuration
- 람다
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
