가령 어떤 은행 시스템이 존재한다고 가정해보자.
A 은행과 B 은행 사이에서 다음과 같은 트랜잭션이 일어나려 한다.
A -> (10만원) -> B
B -> (5만원) -> A
최종적으로 A가 B에게 5만원을 받기만 하면 모든 거래가 깔끔하게 하나의 트랜잭션으로 해결될 수 있다.
하지만 위의 경우 만약 A 또는 B 은행에 잔고가 없더라도 추후 정산할 것을 기대하며 일종의 '신뢰 거래' 가 이뤄질 수도 있다.
이와 같은 방법을 막기 위해 추후에 정산하는 방법이 아닌 동시에 거래들이 이뤄지는 방법을 도입한다고 가정해보자.
그렇다면 동시다발적으로 수많은 트랜잭션이 이뤄질것이다.
다만 DB에서는 lock을 통해 데이터를 보호하려는 속성을 가지고 있다.
즉, A -> B로 계좌이체하는 트랜잭션이 이뤄질 때, DB에 데이터가 완전히 commit 되기 전까지는 조회 및 insert 등의 작업이 이뤄지지 않게 트랜잭션이 완료될때까지 A와 B의 해당 테이블에 'lock' 이 생긴다.
근데 만약 위의 경우처럼 A->B 의 트랜잭션으로 인해 lock이 걸리는 시간과 동시다발적으로 B->A 트랜잭션이 같이 일어난다면?
=> 두개의 트랜잭션에 대한 lock이 서로 걸려 DeadLock(교착 상태)가 일어나게 된다.
DeadLock 해결 방법은?
=> 답이 없다... 스스로 해결되는 것이 아니기 때문에 직접 종료를 통해 해소
============================================================================================
## 그럼 만약 위 은행 프로세스(동시 처리)를 적용하기 위해서는 어떤 점을 고려해야 할까?
=> DeadLock 상황을 피하기 위해서는 각각의 트랜잭션을 병렬처리가 아닌 직렬 처리하는 방안
=> 단 직렬 처리의 경우 CPU core 수와 상관없이 순차적으로 처리가 되어야 되기 때문에 필연적으로 느릴 수밖에 없다.
=> DB에 직렬화하여 트랜잭션을 처리하는 것은, OS 성능과 크게 상관없이 느릴 수밖에 없다.
=> 그러기에 DB 외에 IMDG (In-Memory Data-Grid)의 도입을 통해 향상성을 노리는 것 또한 고려해볼 수 있음.
## IMDG 종류
- coherence
- Apache Ignite
- Redis
- Hazelcast
(관련하여 읽어보면 좋을만한 글 : http://cloudinsight.net/data/%EC%9D%B8%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%BA%90%EC%8B%B1%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EC%B0%B0/)
============================================================================================
## DeadLock 발생 조건 (참조: https://gyoogle.dev/blog/computer-science/operating-system/DeadLock.html)
1. 상호 배제 (Mutual exclusion)
2. 점유 대기 (Hold and wait)
3. 비선점 (No preemption)
4. 순환 대기(Cricular wait)
### DeadLock 처리 방법
1. 예방 (Prevention)
2. 회피 (Avoidance)
3. 탐지 (Detection)
4. 회복 (Recovery)
'개인 공부' 카테고리의 다른 글
2023 하반기 목표 프로젝트 (zabbix~weblogic 모니터링 및 slack 연동) (0) | 2023.08.09 |
---|---|
Hadoop (0) | 2023.06.01 |
공부 커리큘럼 (0) | 2022.07.01 |
궁금증 - 카카오톡은 어떻게 작동할까? (0) | 2022.04.15 |
미들웨어 엔지니어의 로드맵 (0) | 2022.01.21 |