Transaction
서비스에서 큰 문제
- 에러? X
- 장애? X
==> 이런건 기다리면 해결 됨.
- 진짜 큰 문제는 데이터의 오염
ex) 팔렸다고 체크하고 실제로 안팔림
ex) 충전됐다고 뜨고 실제로 충전안됨
==> 이런 로직은 전부 실패로 처리하고, 다시 시도해야 안전하다!
==> 로직들을 Grouping해서 하나라도 실패하면 싹다 실패로 처리하기!
Grouping한 작업 단위 = Transaction
싹다 성공했다 = 커밋
하나라도 실패해서 실패로 처리함 = 롤백
ACID
- A : 원자성 : 오염 안돼
- C : 일관성 : 조회할때마다 동일해야해
- I : 격리성 : A거하고 있으니 B는 기다려
- D : 지속성 : 성공하면 장애 발생해도 살아있어야 해
Lock
하나의 데이터를 서로 다른 곳에서 가져가서 작업할 때,
한 쪽의 데이터가 묻히지 않도록 데이터를 한번에 한명만 가져갈 수 있도록
데이터를 잠구는 행위.
ex) ktx예매하는데 한명이 찜해놓은거 내가 먹으면 말이안된다.
해당 좌석 lock 걸어버리는 것
-
낙관적 락
문제 생기면 나중에 개발자가 로직을 짠다. -
비관적 락
DB에서 처리하도록 데이터 lock 만들기.-공유락(Shared Lock) 읽기 전용으로 만들고 쓰기 잠금.
(코드 : pessimistic_read)-베타락(Exclusive Lock) 읽기 + 쓰기 모두 잠금.
(코드 : pessimistic_write)-로우락 (row lock) : 행만 잠굼
-테이블락 (table lock) : 테이블을 잠굼
데드락
두개의 API가 만날때 lock끼리만나서 API가 둘 다 멈추는 현상
우당탕탕 개발자