디비 데드락

디비 데드락이란?

디비 데드락

 

위 그림처럼 데드락(교착 상태)은 두 개 이상의 트랜잭션이 서로가 점유한 자원을 요청하면서 무한정으로 대기하는 상황이다

이로 인해 해당 트랜잭션들은 더 이상 진행할 수 없게 되어 시스템의 성능과 안정성에 부정적인 영향을 미침

 

 

데드락이 발생하는 조건 

데드락이 발생하기 위해서는 다음 네 가지 조건이 모두 만족되어야 한다

1. 상호 배제(Mutual Exclusion): 자원은 한 번에 한 트랜잭션만 사용
2. 점유와 대기(Hold and Wait): 이미 자원을 점유한 트랜잭션이 추가적인 자원을 요청하며 대기
3. 비선점(No Preemption): 자원을 점유한 트랜잭션은 자발적으로 자원을 해제하기 전까지 그 자원을 강제로 빼앗길 수 없다
4. 순환 대기(Circular Wait): 트랜잭션들이 원형으로 자원을 서로 대기하고 있다. 위의 그림처럼, Transaction1은 Transaction2가 점유하고있는 자원을, Transaction2는 Transaction1의 점유한 자원을 기다리는 상황

 

데드락 예방 (Deadlock Prevention) : 큰 디비에 적합

강제적인 규칙을 통해 시스템이 데드락 조건을 충족시키지 않도록 미리 제약을 두는 방식
자원 요청 자체에 강력한 제한을 미리 걸어버립니다.

• 자원 순서 부여(wait-die) : 모든 자원에 우선순위를 부여하고, 트랜잭션이 자원을 요청할 때 항상 증가하는 순서로 요청하도록 함
  : 예) 테이블별로 먼저 접근해야하는 테이블을 코드상으로 정해놓기,
          한 테이블에서 여러 로우를 접근해야할때 Id가 낮은 순서부터 차례대로 접근하기, 
          타임스템프를 비교하여 우선순위 선정,
• 점유와 대기 방지 : 트랜잭션이 실행되기 전에 필요한 모든 자원을 한꺼번에 요청하여 점유한다
  예) 필요한 자원을 모두 한번에 할당받고 실행이 되는방식, 내가 나중에 필요한 자원을 누군가가 이미 쓰고있다면 대기
  모든 자원이 사용가능 상태가 되었을때 다시 실행
• 선점 허용(would-wait) : 추가 자원을 요청할 때 실패하면, 이미 점유한 자원을 해제하고 다시 시도합니다.

장점:

• 구현이 비교적 간단하며 데드락 발생을 원천적으로 방지함.

단점:

• 자원 활용도가 낮아질 수 있고, 프로세스의 응답 시간이 길어질 수 있음.

데드락 회피 (Deadlock Avoidance) : 작은 디비에 적합

자원을 요청할 때마다 실시간으로 데드락 발생 가능성을 분석하고, 그때그때 안전한 상태인지 판단하여 자원을 할당하거나 거절

작은 디비에 적합한 이유는 실시간으로 시뮬레이션을 수행해야 하는데 이걸 큰 디비에서 하면 매우 복잡해짐

• 은행가 알고리즘: 시스템이 자원 할당 요청을 수락했을 때 안전 상태인지 검사하고, 안전하지 않다면 요청을 거부합니다.

장점:

• 자원 활용 효율이 높고, 프로세스가 필요한 시점에 자원을 할당받을 수 있음.

단점:

• 시스템이 모든 프로세스의 최대 자원 요구량을 사전에 알아야 함.
• 계산 복잡도가 높아지고 구현이 복잡함.

 

 

optimistic lock Lock (낙관적락) vs pessimistic lock(비관적락)

비관적 락:

• 데이터의 충돌이 자주 일어날 것이라고 가정( 데이터 충돌이 빈번한 경우에 적합 )
• 데이터를 읽을 때부터 락을 걸어 다른 트랜잭션이 데이터를 수정하지 못하게 하는것
• 성능 저하: 트랜잭션이 락을 오랫동안 유지하면, 다른 트랜잭션이 해당 데이터에 접근하지 못해 대기 상태가 발생하고, 시스템의 성능이 저하될 수 있음
• 교착 상태(Deadlock): 여러 트랜잭션이 서로 락을 기다리는 상황이 발생하면 교착 상태에 빠질 수 있습니다.

낙관적 락:

• 낙관적 락은 데이터에 대한 충돌이 드물 것이라고 가정하고, 데이터를 읽을 때는 락을 걸지 않고 데이터를 수정할 때만 충돌 여부를 확인하는 방식
• 즉, 데이터를 읽은 후 다른 트랜잭션이 데이터를 변경했는지를 확인하고, 충돌이 발생하지 않았다면 데이터를 업데이트하는 방식

낙관적 락은 주로 Version Number나 타임스탬프를 사용하여 충돌을 감지합니다. 예를 들어, 데이터의 버전 번호를 유지하다가 업데이트 시점에 버전 번호가 바뀌었는지 확인함

만약 다른 트랜잭션이 먼저 데이터를 수정했다면, 업데이트를 실패시키고 다시 시도하거나 오류를 발생시키는 방식으로 처리합니다.