Strong Consistency

1
2
3
4

[클라이언트] → 쓰기 → [주 노드]  
└→ 동기 복제 → [복제본 1]  
└→ 동기 복제 → [복제본 2]  
모든 복제본 승인 후 응답

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

시스템 구성: MySQL 기반 금융 거래 시스템

시나리오:
1. 리더 노드(N1)와 팔로워 노드(N2, N3)로 구성된 클러스터
2. 클라이언트가 계좌 잔액 업데이트 요청: "계좌 A의 잔액을 1000에서 800으로 변경"
3. 요청이 리더 노드 N1으로 라우팅됨
4. N1이 로컬에서 변경 적용 후 바이너리 로그에 기록
5. N1이 N2, N3에 변경사항 전송
6. N2, N3가 변경사항 적용 후 확인 응답
7. 모든 팔로워의 확인 후 N1이 클라이언트에 성공 응답
8. 이후 어떤 노드에서 읽어도 잔액은 800으로 표시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

시스템 구성: 5개 노드(N=5)로 구성된 분산 Key-Value 저장소

시나리오:
1. 쓰기 쿼럼 W=3, 읽기 쿼럼 R=3으로 설정 (W+R=6 > N=5)
2. 클라이언트가 키 K의 값을 "value1"에서 "value2"로 업데이트 요청
3. 코디네이터가 모든 노드에 쓰기 요청 전송
4. 최소 3개 노드(N1, N2, N3)에서 성공 확인을 받으면 클라이언트에 성공 응답
5. 일시적으로 N4, N5는 아직 이전 값("value1") 유지 가능
6. 이후 읽기 요청 시:
   - 최소 3개 노드에서 데이터 조회
   - R=3, W=3이므로 최소 한 노드는 최신 값("value2")을 가짐
   - 버전 비교 후 최신 값("value2") 반환

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

시스템 구성: 3개의 마이크로서비스로 구성된 은행 송금 시스템

시나리오 (A 계좌에서 B 계좌로 100 이체):
1. 트랜잭션 코디네이터(TC)가 트랜잭션 시작
2. 준비 단계:
   - TC: "A 계좌에서 100 출금 준비 가능?"
   - A 서비스: 잔액 확인, 임시 출금 기록, "준비 완료" 응답
   - TC: "B 계좌에 100 입금 준비 가능?"
   - B 서비스: 임시 입금 기록, "준비 완료" 응답
3. 커밋 단계:
   - 모든 서비스가 "준비 완료"이므로, TC가 "커밋" 명령 전송
   - A 서비스: 출금 작업 확정 및 "커밋 완료" 응답
   - B 서비스: 입금 작업 확정 및 "커밋 완료" 응답
4. TC가 트랜잭션 완료 기록

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

시스템 구성: 여러 데이터 센터에 분산된 글로벌 재고 관리 시스템

시나리오 (상품 재고 감소 및 주문 생성):
1. 코디네이터가 트랜잭션 시작
2. 준비 단계(CanCommit):
   - 코디네이터: "재고 감소 및 주문 생성 가능?"
   - 재고 서비스: 재고 확인 후 "가능" 응답
   - 주문 서비스: 주문 생성 가능성 확인 후 "가능" 응답
3. 준비 완료 단계(PreCommit):
   - 코디네이터: 모든 응답이 "가능"이므로 "준비 완료" 명령 전송
   - 재고 서비스: 재고 잠금 및 예약, 실행 로그 생성, "준비 완료" 응답
   - 주문 서비스: 주문 생성 준비, 실행 로그 생성, "준비 완료" 응답
4. 커밋 단계(DoCommit):
   - 코디네이터: "커밋 실행" 명령 전송
   - 재고 서비스: 재고 감소 확정, "커밋 완료" 응답
   - 주문 서비스: 주문 생성 확정, "커밋 완료" 응답
5. 코디네이터: 트랜잭션 완료 기록

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

시스템 구성: 5개의 노드로 구성된 분산 설정 서비스

시나리오 (설정값 "max_connections=500" 적용):
1. 노드 N1이 제안자 역할, 나머지는 수락자 역할
2. 준비 단계:
   - N1이 제안 번호 n=5로 준비 요청 전송
   - 수락자 N2, N3, N4가 이전에 수락한 제안이 없으므로 "준비 완료" 응답
3. 수락 단계:
   - N1이 값 "max_connections=500"과 함께 제안 번호 n=5로 수락 요청 전송
   - N2, N3, N4가 해당 값 수락 및 응답
4. 과반수 수락자가 동의했으므로 값 "max_connections=500"이 결정됨
5. 모든 학습자 노드에 결정된 값 전파

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

시스템 구성: 5개 노드(N1-N5)로 구성된 etcd 클러스터

시나리오:
1. 초기 상태: 모든 노드가 팔로워 상태, 임기(term)는 0
2. 리더 선출:
   - N1의 선거 타임아웃 발생, 상태를 후보자로 변경, 임기를 1로 증가
   - N1이 자신에게 투표하고 다른 노드들에게 투표 요청
   - N2, N3, N4가 N1에 투표 (과반수 획득)
   - N1이 리더가 되어 하트비트 전송 시작
3. 로그 복제:
   - 클라이언트가 키 K의 값을 "value1"로 설정 요청
   - 리더 N1이 로그에 명령 추가 (인덱스 1, 임기 1)
   - N1이 팔로워들에게 로그 엔트리 복제 요청
   - 과반수 복제(N2, N3, N5) 확인 후 커밋
   - N1이 상태 머신에 명령 적용 후 클라이언트에 응답
   - 팔로워들도 커밋된 명령 적용

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

시스템 구성: 3개 노드로 구성된 ZooKeeper 앙상블

시나리오:
1. 초기 상태: N1이 리더, N2, N3가 팔로워
2. 클라이언트가 znode "/config"에 값 설정 요청
3. 브로드캐스트 단계:
   - 리더 N1이 트랜잭션 ID(zxid) 5를 할당
   - N1이 팔로워들에게 제안(zxid=5, 값="/config:new_value") 전송
   - N2, N3가 제안을 로그에 기록 후 확인 응답
   - 과반수 확인 후 N1이 커밋 메시지 브로드캐스트
   - 모든 서버가 트랜잭션 적용 및 클라이언트에 응답
4. 리더 N1 장애 발생:
   - N2, N3이 리더 선출 시작
   - N3이 새 리더로 선출
   - 동기화 단계에서 N3가 마지막 커밋된 zxid 확인
   - N2와 동기화 후 새로운 요청 처리 재개

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

시스템 구성: Redis나 ZooKeeper를 락 관리자로 사용하는 마이크로서비스 아키텍처

시나리오 (사용자 프로필 업데이트):
1. 서비스 인스턴스 S1이 사용자 ID 123에 대한 락 요청
   - Redis 명령: SET user:123:lock S1_ID NX PX 10000 (10초 타임아웃)
   - 락 획득 성공
2. S1이 사용자 프로필 데이터베이스 업데이트 수행
3. 동시에 서비스 인스턴스 S2도 같은 사용자 프로필 업데이트 시도
   - 같은 락 요청 명령 실행
   - Redis가 이미 키가 존재하므로 실패 응답
   - S2는 대기하거나 나중에 재시도
4. S1이 작업 완료 후 락 해제
   - DEL user:123:lock 명령 실행
5. S2가 락 재시도하여 획득 및 작업 수행

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

시스템 구성: 주문, 재고, 결제, 배송 서비스로 구성된 이커머스 플랫폼

시나리오 (새 주문 처리):
1. 트랜잭션 관리자가 글로벌 트랜잭션 ID 생성
2. 주문 서비스: 주문 생성 및 로컬 트랜잭션 준비
3. 재고 서비스: 재고 확인 및 할당 트랜잭션 준비
4. 결제 서비스: 결제 승인 트랜잭션 준비
5. 배송 서비스: 배송 계획 생성 트랜잭션 준비
6. 모든 서비스가 준비 완료 응답 시:
   - 트랜잭션 관리자가 각 서비스에 커밋 명령
   - 각 서비스가 로컬 트랜잭션 커밋 및 확인
7. 일부 서비스 실패 시:
   - 트랜잭션 관리자가 롤백 명령
   - 각 서비스가 로컬 트랜잭션 롤백 및 확인

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

시스템 구성: 1개의 주 노드와 2개의 부 노드를 가진 PostgreSQL 데이터베이스

시나리오:
1. 시스템 설정: synchronous_commit = on, synchronous_standby_names = 'node2, node3'
2. 클라이언트가 중요 재무 데이터 업데이트 요청
3. 주 노드가 로컬 변경 적용 및 WAL(Write-Ahead Log) 생성
4. WAL 레코드가 node2와 node3로 전송
5. 두 부 노드가 WAL 적용 및 디스크에 기록 후 확인 응답
6. 주 노드가 두 부 노드의 확인을 받은 후 클라이언트에 성공 응답
7. 이로써 최소 3개 노드에 데이터가 안전하게 저장됨을 보장

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

시스템 구성: Google Spanner와 유사한 글로벌 분산 데이터베이스

시나리오:
1. 시스템이 TrueTime API를 사용하여 글로벌 타임스탬프 제공
   - 각 타임스탬프는 [earliest, latest] 범위로 표현
2. 트랜잭션 T1이 시작:
   - 시작 타임스탬프: [10:00:01.000, 10:00:01.001] 할당
3. T1이 데이터 읽기 및 수정 후 커밋 준비
   - 커밋 타임스탬프: [10:00:02.000, 10:00:02.001] 할당
4. 시스템이 불확실성 대기:
   - 실제 시간이 10:00:02.001 이후가 될 때까지 대기
5. 대기 후 T1 커밋
6. 다른 트랜잭션 T2가 시작:
   - 시작 타임스탬프가 T1의 커밋 타임스탬프보다 큰 경우
   - T2는 T1의 결과를 볼 수 있음

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

시스템 구성: MVCC를 구현한 PostgreSQL 데이터베이스

시나리오:
1. 트랜잭션 T1이 10:00:00에 시작:
   - 시스템이 T1에 타임스탬프 100 할당
2. T1이 레코드 R1 읽기(값: "A")
3. 트랜잭션 T2가 10:00:05에 시작:
   - 시스템이 T2에 타임스탬프 105 할당
4. T2가 R1 업데이트: "A" → "B"
   - 시스템이 R1의 새 버전 생성: (R1, "B", 105)
   - 이전 버전은 유지: (R1, "A", < 105)
5. T2가 커밋
6. T1이 다시 R1 읽기 시도:
   - T1의 타임스탬프(100)에 따라 이전 버전 (R1, "A", < 105) 반환
   - 트랜잭션 격리 보장
7. T1이 커밋
8. 새 트랜잭션 T3가 10:00:10에 시작:
   - R1 읽기 시 최신 버전 (R1, "B", 105) 반환

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

시스템 구성: 5개 노드로 구성된 소규모 클러스터 데이터베이스(예: SQLite 복제)

시나리오:
1. 클러스터가 Raft 합의 알고리즘을 사용하여 리더 선출
2. 클라이언트가 데이터 삽입 요청:
   - SQL: "INSERT INTO users VALUES (101, 'Alice', 'alice@example.com')"
3. 리더가 명령을 로그 엔트리로 변환하여 Raft 로그에 추가
4. 리더가 로그 엔트리를 모든 팔로워에게 복제
5. 과반수 복제 확인 후 리더가 커밋 지점 진행
6. 모든 노드가 커밋된 명령을 동일한 순서로 SQLite 데이터베이스에 적용
7. 리더가's 클라이언트에 성공 응답
8. 어떤 노드에 쿼리하더라도 동일한 데이터 확인 가능

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

시스템 구성: 선형화 가능성을 보장하는 분산 키-값 저장소

시나리오:
1. 초기값: x = 0
2. 클라이언트 C1이 10:00:01에 x 읽기 → 0 반환
3. 클라이언트 C2가 10:00:02에 x = 1 쓰기
4. 클라이언트 C3가 10:00:03에 x 읽기 요청
   - 선형화 가능성에 의해 반드시 1 반환
5. 클라이언트 C1이 10:00:04에 다시 x 읽기 요청
   - 선형화 가능성에 의해 반드시 1 반환
6. 네트워크 지연이나 노드 장애가 있더라도:
   - 시스템은 C2의 쓰기가 시간상 C3의 읽기보다 앞서므로 
     C3는 반드시 1을 봐야 함
   - 이전에 0을 읽은 C1도 새 읽기에서는 반드시 1을 봐야 함

 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

시스템 구성: 소프트웨어 거래 메모리(STM)를 구현한 분산 인메모리 데이터베이스

시나리오:
1. 다중 노드 환경에서 고객 잔액 업데이트 함수 실행:

	```java
	atomic {
	    // 트랜잭션 시작
	    Account A = accounts.get("A");
	    Account B = accounts.get("B");
	    
	    int amount = 100;
	    if (A.balance >= amount) {
	        A.balance -= amount;  // 읽기-수정-쓰기 연산
	        B.balance += amount;  // 읽기-수정-쓰기 연산
	    }
	    // 트랜잭션 종료
	}
	```

2. 동시에 다른 노드에서 같은 계정에 접근:
    - STM 시스템이 트랜잭션 로그 및 버전 기록
    - 충돌 감지: 다른 트랜잭션이 이미 변경 중인 객체 감지
    - 해결: 한 트랜잭션 커밋, 충돌 트랜잭션 자동 재시도
3. 결과적으로 계정 A와 B의 잔액 합계는 일관적으로 유지됨

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

시스템 구성: 블록체인 기반 분산 원장 시스템

시나리오:

1. 시스템에 다음 트랜잭션 추가:
    - Tx1: "Alice가 Bob에게 5코인 전송"
    - Tx2: "Bob이 Charlie에게 2코인 전송"
2. 각 트랜잭션의 해시 생성:
    - H(Tx1) = a1b2c3…
    - H(Tx2) = d4e5f6…
3. 트랜잭션으로부터 머클 트리 구성:
    - 루트 해시 = H(H(Tx1) + H(Tx2))
4. 새 블록 생성 및 이전 블록과 연결
5. 클라이언트가 Tx1의 포함 여부 검증 요청:
    - 서버가 머클 증명 생성: Tx1, H(Tx2), 루트 해시
    - 클라이언트가 로컬에서 계산:
        - H(Tx1) = a1b2c3…
        - H(a1b2c3… + d4e5f6…) = 루트 해시
    - 계산 결과가 제공된 루트 해시와 일치하면 포함 확인
6. 데이터 변조 시도 시 해시 불일치로 즉시 감지 가능

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

시스템 구성: Google Spanner와 같은 전역 분산 데이터베이스

시나리오:

1. 초기 상태: 계좌 A = 1000, 계좌 B = 500
2. 트랜잭션 T1 (10:00:01 시작):
    
    ```sql
    BEGIN;UPDATE accounts SET balance = balance - 100 WHERE id = 'A';UPDATE accounts SET balance = balance + 100 WHERE id = 'B';COMMIT;
    ```
    
3. 트랜잭션 T2 (10:00:02 시작):
    
    ```sql
    BEGIN;SELECT balance FROM accounts WHERE id IN ('A', 'B');COMMIT;
    ```
    
4. 엄격한 직렬화 보장:
    - T1이 T2보다 실제 시간상 먼저 시작되었으므로
    - T2는 반드시 T1의 변경사항이 적용된 상태(A=900, B=600)를 관찰해야 함
    - 모든 노드에서도 동일한 결과 관찰
5. 어떤 노드에 쿼리하더라도 트랜잭션 간 순서는 실제 시간 순서와 일치

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

시스템 구성: 여러 데이터 센터에 분산된 CockroachDB 클러스터

시나리오:

1. 현재 HLC(Hybrid Logical Clock) 시간: 1621234567.000
2. 트랜잭션 T1 시작:
    - 시스템이 T1에 타임스탬프 1621234567.100 할당
    - T1에게 해당 시점의 일관된 데이터베이스 스냅샷 제공
3. 트랜잭션 T2가 테이블 X 업데이트:
    - 타임스탬프 1621234567.200 할당
    - 변경사항 커밋
4. T1이 테이블 X 읽기:
    - T1의 타임스탬프(1621234567.100)보다 이후에 발생한 T2의 변경사항(1621234567.200)은 보이지 않음
    - T1은 자신의 타임스탬프 시점의 일관된 스냅샷 유지
5. T1이 테이블 X와 Y에 대한 여러 읽기 작업 수행:
    - 모든 읽기가 동일한 시점의 일관된 데이터 반환
6. T1이 테이블 Z 업데이트 시도 및 커밋:
    - 다른 트랜잭션과 쓰기-쓰기 충돌 없으면 성공

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

시스템 구성: 다중 노드 분산 데이터베이스, 버전 번호 기반 OCC 사용

시나리오:

1. 객체 X의 초기 버전: v1, 값: "data1"
2. 트랜잭션 T1이 X 읽기:
    - X의 현재 버전 v1과 값 "data1" 로컬 저장
3. 트랜잭션 T2도 X 읽기:
    - X의 현재 버전 v1과 값 "data1" 로컬 저장
4. T1이 X 수정: 값을 "data1-T1"으로 변경
5. T1 커밋 시도:
    - 유효성 검사: X의 현재 버전이 여전히 v1인지 확인 → 성공
    - X 업데이트: 버전 v2, 값 "data1-T1"
6. T2가 X 수정: 값을 "data1-T2"로 변경
7. T2 커밋 시도:
    - 유효성 검사: X의 현재 버전이 v1이 아닌 v2로 변경됨 → 실패
    - T2 중단 및 재시도 또는 사용자에게 충돌 알림

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

시스템 구성: 중앙 마스터와 여러 복제 슬레이브로 구성된 파일 저장 시스템

시나리오:

1. 클라이언트가 파일 F 업데이트 요청
2. 요청이 중앙 마스터 서버로 라우팅됨
3. 마스터 서버가 변경사항 적용 및 로그 기록
4. 마스터가 모든 슬레이브에 변경사항 전파
5. 각 슬레이브가 변경사항 적용 후 확인 응답
6. 모든(또는 쿼럼의) 슬레이브의 확인 후 클라이언트에 성공 응답
7. 이후 어떤 서버에서 읽어도 업데이트된 파일 내용 확인 가능

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

시스템 구성: 다중 노드 PostgreSQL 데이터베이스 클러스터

시나리오:

1. 트랜잭션 T 시작:
    
    ```sql
    BEGIN;UPDATE accounts SET balance = balance - 100 WHERE id = 1;UPDATE accounts SET balance = balance + 100 WHERE id = 2;
    ```
    
2. 각 UPDATE 문에 대한 WAL 레코드 생성:
    - LSN 1000: 계정 1 잔액 수정 (1000 → 900)
    - LSN 1001: 계정 2 잔액 수정 (500 → 600)
3. WAL 레코드를 디스크에 기록 및 동기화
4. 데이터 페이지 수정 (아직 디스크에 기록되지 않을 수 있음)
5. 트랜잭션 커밋 WAL 레코드 생성 및 동기화:
    - LSN 1002: 트랜잭션 T 커밋
6. 클라이언트에 성공 응답
7. 시스템 장애 발생 및 재시작:
    - WAL에서 커밋된 트랜잭션 T 발견
    - LSN 1000-1002 레코드 재실행하여 데이터 일관성 복구

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

시스템 구성: 10개 노드(최대 3개 악의적 노드 허용)로 구성된 PBFT(Practical Byzantine Fault Tolerance) 시스템

시나리오:

1. 클라이언트가 요청 R을 시스템에 전송
2. 주 노드(primary)가 요청을 수신하고 순서 번호 n 할당
3. 전처리 단계:
    - 주 노드가 <PRE-PREPARE, n, R, sig_p> 메시지를 모든 백업 노드에 전송
4. 준비 단계:
    - 각 백업 노드가 메시지 유효성 검증
    - 유효하면 <PREPARE, n, R, i, sig_i> 메시지를 모든 노드에 브로드캐스트
5. 커밋 단계:
    - 각 노드가 동일한 요청에 대해 2f+1개 이상의 PREPARE 메시지 수신
    - <COMMIT, n, R, i, sig_i> 메시지를 모든 노드에 브로드캐스트
6. 실행:
    - 각 노드가 동일한 요청에 대해 2f+1개 이상의 COMMIT 메시지 수신
    - 요청 실행 및 클라이언트에 응답
7. 클라이언트가 f+1개 이상의 동일한 응답 수신 시 결과 승인

1
2
3
4

[사용자] → [주 노드: 잔액 감소]  
→ 복제본 1: 동기 업데이트 ✔️  
→ 복제본 2: 동기 업데이트 ✔️  
→ 트랜잭션 완료 → 사용자에게 성공 통보