Sequential Consistency

1
2
3
4

P1: W(x) ----> R(y)
P2:      W(y) ----> R(x)

가능한 글로벌 순서: W(x) -> W(y) -> R(x) -> R(y)

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

시스템 구성: 중앙 시퀀서 S와 복제 노드 R1, R2, R3

시나리오:
1. 클라이언트 C1이 R1에 쓰기 요청: "x = 1"
2. R1이 요청을 시퀀서 S에 전달
3. S가 요청에 순서 번호 10 할당
4. S가 "op(10): x = 1"을 모든 복제 노드에 브로드캐스트
5. 클라이언트 C2가 R2에 쓰기 요청: "x = 2"
6. R2가 요청을 S에 전달, S가 순서 번호 11 할당
7. S가 "op(11): x = 2"를 모든 노드에 브로드캐스트
8. 클라이언트 C3가 R3에 읽기 요청: "read x"
9. R3가 요청을 S에 전달, S가 순서 번호 12 할당
10. 각 노드는 순서 번호에 따라 작업 실행:
    - 모든 노드: op(10) 실행 → x = 1
    - 모든 노드: op(11) 실행 → x = 2
    - 모든 노드: op(12) 실행 → x = 2 반환
11. R3가 C3에게 결과 "x = 2" 반환

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

시스템 구성: 4개 노드(N1, N2, N3, N4)의 분산 캐시 시스템, ISIS 프로토콜 사용

시나리오:
1. 클라이언트 A가 N1을 통해 SET(k1, v1) 요청
2. N1이 멀티캐스트 그룹에 메시지 M1: {op: SET, key: k1, value: v1} 전송
   - 멀티캐스트 계층이 메시지 시퀀스 번호 할당 과정 수행
   - 순서 합의 프로토콜 실행
   - M1에 시퀀스 번호 100 할당
3. 동시에 클라이언트 B가 N3를 통해 SET(k1, v2) 요청
4. N3가 멀티캐스트 그룹에 메시지 M2: {op: SET, key: k1, value: v2} 전송
   - 순서 합의 후 M2에 시퀀스 번호 101 할당
5. 노드 N1, N2, N3, N4 모두 M1(100)과 M2(101)를 동일한 순서로 수신
6. 모든 노드가 동일한 순서로 작업 실행:
   - 시퀀스 100: k1 = v1 설정
   - 시퀀스 101: k1 = v2 설정 (이전 값 덮어씀)
7. 클라이언트 C가 N2에서 GET(k1) 요청
8. N2가 로컬에서 k1 = v2 반환
9. 모든 노드의 k1 값이 v2로 동일

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

시스템 구성: 3개 노드(A, B, C)를 가진 분산 시스템

시나리오:
1. 초기 논리적 시계: A=0, B=0, C=0
2. 노드 A에서 이벤트 발생: A의 시계 증가 → A=1
3. A가 노드 B에 메시지 전송: 타임스탬프 1 포함
4. B가 메시지 수신: 
   - B의 시계 업데이트: max(B=0, received=1) + 1 = 2
   - B=2
5. B에서 이벤트 발생: B의 시계 증가 → B=3
6. C에서 이벤트 발생: C의 시계 증가 → C=1
7. C가 B에 메시지 전송: 타임스탬프 1 포함
8. B가 C의 메시지 수신:
   - B의 시계 업데이트: max(B=3, received=1) + 1 = 4
   - B=4
9. 작업 순서 결정 시 (타임스탬프, 노드ID) 튜플 비교:
   - A의 작업: (1, A)
   - B의 첫 작업: (3, B)
   - C의 작업: (1, C)
   - B의 두 번째 작업: (4, B)
10. 튜플 순서: (1, A) < (1, C) < (3, B) < (4, B)

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

시스템 구성: 기본 노드 P와 백업 노드 B1, B2

시나리오:
1. 초기 상태: 모든 노드의 x = 0, y = 0
2. 클라이언트 C1이 P에 쓰기 요청: "x = 1"
3. P가 로컬 상태 업데이트: x = 1
4. P가 업데이트 로그 {op: "SET", key: "x", value: 1, seq: 1}를 B1, B2에 전송
5. B1, B2가 로그 적용: x = 1
6. 클라이언트 C2가 P에 쓰기 요청: "y = x + 1" (y = 2)
7. P가 로컬 상태 업데이트: y = 2
8. P가 업데이트 로그 {op: "SET", key: "y", value: 2, seq: 2}를 B1, B2에 전송
9. B1, B2가 로그 적용: y = 2
10. 기본 노드 P에 장애 발생
11. B1이 새 기본 노드로 승격
12. 클라이언트 C3가 B1(새 기본)에 읽기 요청: "read y"
13. B1이 "y = 2" 반환

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

시스템 구성: 시퀀스 관리자 S와 데이터 노드 N1, N2, N3

시나리오:
1. 클라이언트 A가 N1에 키 K의 값을 "value1"로 설정 요청
2. N1이 시퀀스 관리자 S에 시퀀스 번호 요청
3. S가 시퀀스 번호 100 할당
4. N1이 로컬에 (K, "value1", seq=100) 저장 및 다른 노드에 복제 요청 전송
5. 클라이언트 B가 N2에 같은 키 K의 값을 "value2"로 설정 요청
6. N2가 S에 시퀀스 번호 요청, S가 101 할당
7. N2가 로컬에 (K, "value2", seq=101) 저장 및 복제 요청 전송
8. 노드 N3가 시퀀스 100과 101인 두 쓰기 작업을 수신:
   - 시퀀스 번호 순서대로 적용
   - 먼저 K = "value1" (seq=100) 설정
   - 그 다음 K = "value2" (seq=101) 설정
9. 클라이언트 C가 N3에 키 K 읽기 요청
10. N3가 최종 값 "value2" 반환

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

시스템 구성: 마스터 노드 M과 복제 노드 R1, R2

시나리오:
1. 마스터 M이 각 복제 노드와 전용 TCP 연결 유지
2. 클라이언트가 M에 쓰기 요청 시퀀스 전송:
   - "x = 10"
   - "y = 20"
   - "z = x + y" (= 30)
3. M이 로컬에서 명령 실행:
   - x = 10
   - y = 20
   - z = 30
4. M이 동일한 명령을 TCP 연결을 통해 R1, R2에 전송
5. TCP의 순서 보장 특성으로 R1, R2는 메시지를 정확한 순서로 수신:
   - "x = 10"
   - "y = 20"
   - "z = x + y"
6. R1, R2가 수신 순서대로 명령 실행:
   - x = 10
   - y = 20
   - z = 30
7. 결과적으로 M, R1, R2 모두 동일한 상태: x=10, y=20, z=30

 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

시스템 구성: 3개 프로세스(P1, P2, P3)로 구성된 분산 시스템

시나리오:
1. 초기 벡터 클럭: P1[1,0,0], P2[0,1,0], P3[0,0,1]
2. P1이 메시지 M1("x = 1") 브로드캐스트:
   - M1에 벡터 클럭 [2,0,0] 첨부
3. P2가 M1 수신:
   - P2의 벡터 클럭 업데이트: max([2,0,0], [0,1,0]) = [2,1,0]
4. P2가 메시지 M2("y = x + 1") 브로드캐스트:
   - M2에 벡터 클럭 [2,2,0] 첨부
5. P3가 M2를 M1보다 먼저 수신:
   - P3의 벡터 클럭: [0,0,1]
   - M2의 벡터 클럭 [2,2,0] 확인
   - [0,0,1]가 [2,2,0]보다 작으므로 M2의 의존성 충족되지 않음
   - M2 전달 지연 및 버퍼에 저장
6. P3가 M1 수신:
   - P3의 벡터 클럭 업데이트: max([2,0,0], [0,0,1]) = [2,0,1]
   - M1("x = 1") 전달 및 적용
7. P3가 버퍼의 M2 재확인:
   - P3의 벡터 클럭 [2,0,1]
   - M2의 의존성 [2,2,0] 확인
   - 아직 충족되지 않음(P3가 P2의 로컬 이벤트 아직 미수신)
8. P2의 로컬 이벤트 메시지가 P3에 도달:
   - P3의 벡터 클럭 업데이트: [2,2,1]
   - M2의 의존성 충족됨
   - M2("y = x + 1") 전달 및 적용

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

시스템 구성: 4개 노드, 가중치 N1=2, N2=2, N3=1, N4=1 (총 6)
             쓰기 쿼럼 W=4, 읽기 쿼럼 R=3

시나리오:
1. 클라이언트가 키 K를 "value1"로 설정 요청
2. 시스템이 쓰기 쿼럼(W=4) 충족을 위해 노드 선택:
   - N1(가중치 2)과 N2(가중치 2) 선택(총 가중치 4)
   - N1, N2에 (K, "value1", version=1) 쓰기
3. 클라이언트가 K 읽기 요청
4. 시스템이 읽기 쿼럼(R=3) 충족을 위해 노드 선택:
   - N3(가중치 1)과 N4(가중치 1) 선택(총 가중치 2)
   - 쿼럼 부족으로 N1(가중치 2) 추가(총 가중치 4)
5. 읽기 결과 비교:
   - N1: (K, "value1", version=1)
   - N3, N4: 값 없음 또는 이전 버전
6. 가장 높은 버전의 값 "value1" 반환
7. 배경에서 N3, N4에 최신 값 전파

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

시스템 구성: Kafka와 같은 분산 로그 시스템과 여러 소비자 노드

시나리오:
1. 클라이언트 A가 작업 "x = 1" 제출
2. 시스템이 작업을 로그의 인덱스 100에 기록
3. 클라이언트 B가 작업 "y = x * 2" 제출
4. 시스템이 작업을 로그의 인덱스 101에 기록
5. 클라이언트 C가 작업 "z = y + 3" 제출
6. 시스템이 작업을 로그의 인덱스 102에 기록
7. 소비자 노드 N1, N2, N3가 로그를 순차적으로 소비:
   - 인덱스 100: "x = 1" 실행 → x = 1
   - 인덱스 101: "y = x * 2" 실행 → y = 2
   - 인덱스 102: "z = y + 3" 실행 → z = 5
8. 결과적으로 모든 노드가 같은 상태: x=1, y=2, z=5

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

시스템 구성: 3개 노드(N1, N2, N3)의 분산 데이터베이스

시나리오:
1. 각 노드가 로컬 논리적 시계 유지
2. 트랜잭션 T1이 N1에서 시작: 
   - N1의 시계 = 10
   - T1에 타임스탬프 TS(T1) = 10 할당
3. T1이 데이터 항목 D 읽기 (현재 값 = "old", TS(D) = 5)
4. T1이 D를 "new1"로 업데이트:
   - TS(T1) = 10 > TS(D) = 5이므로 업데이트 성공
   - D = "new1", TS(D) = 10으로 업데이트
5. 트랜잭션 T2가 N2에서 시작:
   - N2의 시계 = 8
   - T2에 타임스탬프 TS(T2) = 8 할당
6. T2가 D 읽기 시도:
   - 이미 TS(D) = 10 > TS(T2) = 8로 T2의 타임스탬프보다 최신 값이 있음
   - 시스템이 T2를 중단하거나 재시작
7. 트랜잭션 T3가 N3에서 시작:
   - N3의 시계 = 15
   - T3에 타임스탬프 TS(T3) = 15 할당
8. T3가 D 읽기 및 "new2"로 업데이트:
   - TS(T3) = 15 > TS(D) = 10이므로 성공
   - D = "new2", TS(D) = 15
9. 복제 과정에서 모든 노드가 최종적으로 D = "new2", TS(D) = 15로 수렴

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

시스템 구성: 3개 프로세스(P1, P2, P3)의 분산 시스템

시나리오:
1. P1이 메시지 시퀀스 전송:
   - M1: "x = 1" (순서 번호 1)
   - M2: "y = 2" (순서 번호 2)
2. P2도 메시지 시퀀스 전송:
   - N1: "a = 3" (순서 번호 1)
   - N2: "b = 4" (순서 번호 2)
3. 네트워크 지연으로 메시지가 P3에 다음 순서로 도착:
   - M2(P1, 순서 2), N1(P2, 순서 1), M1(P1, 순서 1), N2(P2, 순서 2)
4. FIFO 전달 계층 동작:
   - M2는 P1에서 온 첫 메시지지만 순서 번호가 2
   - M2를 버퍼에 보관(P1의 순서 1 메시지 대기)
   - N1은 P2에서 온 첫 메시지고 순서 번호가 1이므로 전달
   - M1이 도착, P1의 순서 1 메시지이므로 전달
   - 버퍼의 M2도 이제 전달 가능하므로 전달
   - N2는 P2의 순서 2 메시지이고 이전 메시지 모두 전달되었으므로 전달
5. P3에서의 최종 메시지 전달 순서:
   - N1("a = 3"), M1("x = 1"), M2("y = 2"), N2("b = 4")
6. 각 송신자의 메시지는 송신 순서대로 처리됨

 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

시스템 구성: 스냅샷 격리를 구현한 분산 데이터베이스

시나리오:
1. 초기 상태: 계정 A = 1000, 계정 B = 500
2. 트랜잭션 T1 시작(타임스탬프 100):
   - T1이 A와 B의 스냅샷 생성: A = 1000, B = 500
3. 트랜잭션 T2 시작(타임스탬프 101):
   - T2도 같은 스냅샷 확인: A = 1000, B = 500
4. T1이 A에서 B로 300 이체 시도:
   - 읽기 집합: {A = 1000, B = 500}
   - 쓰기 집합: {A = 700, B = 800}
5. 동시에 T2가 A에서 200 인출 시도:
   - 읽기 집합: {A = 1000}
   - 쓰기 집합: {A = 800}
6. T1이 먼저 커밋 시도:
   - 쓰기-쓰기 충돌 없음
   - 커밋 성공, 버전 정보 업데이트:
     * A: 버전 100: 1000, 버전 102: 700
     * B: 버전 100: 500, 버전 102: 800
7. T2가 커밋 시도:
   - 쓰기 집합 {A}가 T1의 쓰기 집합과 충돌
   - 시스템 정책에 따라 T2 중단 또는 재시도
8. T2가 재시도(타임스탬프 103):
   - 새 스냅샷 생성: A = 700, B = 800
   - A에서 200 인출: A = 500
   - 커밋 성공, 새 버전 정보:
     * A: 버전 102: 700, 버전 104: 500
9. 트랜잭션 T3 시작(타임스탬프 105):
   - T3의 스냅샷: A = 500, B = 800
   - 모든 이전 커밋된 변경사항이 반영된 일관된 뷰

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

시스템 구성: 3개 복제 서버(R1, R2, R3)를 가진 분산 데이터 저장소

시나리오:
1. 클라이언트가 입력 I1("set x=5") 전송
2. 입력이 원자적 브로드캐스트 프로토콜을 통해 모든 복제본에 전달됨
   - 브로드캐스트 프로토콜이 I1에 순서 번호 1 할당
3. 각 복제본이 독립적으로 입력 처리:
   - R1, R2, R3 모두 "set x=5" 실행 → x = 5
4. 클라이언트가 입력 I2("increment x") 전송
   - 브로드캐스트 프로토콜이 I2에 순서 번호 2 할당
5. 각 복제본이 독립적으로 I2 처리:
   - R1, R2, R3 모두 "increment x" 실행 → x = 6
6. 복제본 R2가 일시적으로 네트워크에서 분리됨
7. 클라이언트가 입력 I3("set y=x*2") 전송
   - 브로드캐스트 프로토콜이 I3에 순서 번호 3 할당
8. 활성 복제본 R1, R3이 I3 처리:
   - "set y=x*2" 실행 → y = 12
9. R2가 네트워크에 다시 연결됨
10. R2가 놓친 작업 I3 수신 및 처리:
    - "set y=x*2" 실행 → y = 12
11. 최종적으로 모든 복제본이 동일한 상태: x=6, y=12

 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
32
33

시스템 구성: STM 기반 분산 인메모리 객체 저장소

시나리오:
1. 프로그램 코드:
   ```java
   atomic {
       // 트랜잭션 시작
       int x = objects.get("x"); // 읽기 집합에 x 추가
       int y = objects.get("y"); // 읽기 집합에 y 추가
       objects.put("x", x + 1);  // 쓰기 집합에 x 추가
       objects.put("z", x + y);  // 쓰기 집합에 z 추가
   } // 트랜잭션 커밋 시도
	```

2. 초기 상태: x = 5, y = 10, z = 0
3. 스레드 T1이 위 코드 실행, 읽기 집합 {x=5, y=10}, 쓰기 집합 {x=6, z=15}
4. 동시에 스레드 T2가 다른 코드 실행:
    
    ```java
    atomic {    int x = objects.get("x");    objects.put("y", x * 2);}
    ```
    
5. T2의 읽기 집합 {x=5}, 쓰기 집합 {y=10}
6. T1이 먼저 커밋 시도:
    - 읽기/쓰기 집합 검증: 아직 충돌 없음
    - 성공적으로 커밋: x=6, z=15 (y는 변경 없음)
7. T2가 커밋 시도:
    - 읽기 집합 검증: x=5로 읽었지만 현재 x=6
    - 검증 실패, 트랜잭션 재시도
8. T2 재시도:
    - 새 읽기 집합 {x=6}, 쓰기 집합 {y=12}
    - 검증 성공, 커밋: y=12
9. 최종 상태: x=6, y=12, z=15

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

시스템 구성: 3개 프로세스(P1, P2, P3)와 토큰 기반 조정자

시나리오:

1. 초기 상태: 공유 객체 O = {x: 0, y: 0}
2. 조정자가 실행 순서 결정: P1 → P2 → P3
3. 프로세스 P1이 토큰 획득 및 활성화:
    - P1이 객체 수정: O.x = 10
    - P1이 토큰 반환
4. 프로세스 P2가 토큰 획득 및 활성화:
    - P2가 객체 읽기: O.x = 10
    - P2가 객체 수정: O.y = O.x * 2 = 20
    - P2가 토큰 반환
5. 프로세스 P3가 토큰 획득 및 활성화:
    - P3가 객체 읽기: O.x = 10, O.y = 20
    - P3가 객체 수정: O.z = O.x + O.y = 30
    - P3가 토큰 반환
6. 모든 프로세스가 O = {x: 10, y: 20, z: 30}의 일관된 상태 관찰

 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

시스템 구성: 4개 노드(A, B, C, D)를 가진 분산 시스템

시나리오:

1. 초기 논리적 시계: A=1, B=1, C=1, D=1
2. 노드 A에서 로컬 이벤트 e1 발생: A=2
3. A가 B에 메시지 m1 전송: 타임스탬프 2 포함
4. B가 m1 수신:
    - B의 시계 업데이트: max(B=1, received=2) + 1 = 3
    - B=3
5. 노드 C에서 로컬 이벤트 e2 발생: C=2
6. C가 D에 메시지 m2 전송: 타임스탬프 2 포함
7. D가 m2 수신:
    - D의 시계 업데이트: max(D=1, received=2) + 1 = 3
    - D=3
8. B가 C에 메시지 m3 전송: 타임스탬프 3 포함
9. C가 m3 수신:
    - C의 시계 업데이트: max(C=2, received=3) + 1 = 4
    - C=4
10. 모든 이벤트에 할당된 논리적 타임스탬프:
    - e1: (A, 2)
    - 메시지 m1 수신: (B, 3)
    - e2: (C, 2)
    - 메시지 m2 수신: (D, 3)
    - 메시지 m3 수신: (C, 4)
11. 타임스탬프 순서: (A) < (C) < (B) = (D) < (C)

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

시스템 구성: 5개 노드(N1-N5)로 구성된 Raft 기반 분산 시스템

시나리오:

1. 초기 상태: N1이 리더, 임기(term) 1
2. 클라이언트가 명령 C1("set x=5") 전송
3. 리더 N1이 로그 인덱스 10에 C1 추가
4. N1이 팔로워들에게 AppendEntries RPC 전송
5. 팔로워들(N2-N5)이 각자의 로그에 C1 추가
6. 과반수 확인(N1, N2, N3) 후 N1이 커밋 인덱스를 10으로 업데이트
7. 클라이언트가 명령 C2("set y=10") 전송
8. 리더 N1이 로그 인덱스 11에 C2 추가 및 복제
9. N1에 장애 발생, 새 리더 선출
10. N3가 새 리더로 선출됨(임기 2)
11. N3가 이전에 커밋된 로그 확인 및 상태 유지
12. 클라이언트가 명령 C3("set z=x+y") 전송
13. 새 리더 N3가 로그 인덱스 12에 C3 추가 및 복제
14. 모든 노드가 최종적으로 동일한 명령 시퀀스 실행:
    - C1: x = 5
    - C2: y = 10
    - C3: z = 15

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

시스템 구성: 메시지 큐 MQ와 여러 작업자 노드(W1, W2, W3)

시나리오:

1. 클라이언트가 MQ에 작업 시퀀스 제출:
    - 작업 A: "create user X"
    - 작업 B: "add user X to group Y"
    - 작업 C: "send welcome email to X"
2. MQ가 작업을 FIFO 순서로 유지
3. 작업자 W1이 작업 A를 큐에서 가져와 처리:
    - 데이터베이스에 사용자 X 생성
    - 처리 완료 표시
4. 작업자 W2가 작업 B를 큐에서 가져와 처리:
    - 사용자 X를 그룹 Y에 추가
    - 처리 완료 표시
5. 작업자 W3가 작업 C를 큐에서 가져와 처리:
    - 사용자 X에게 환영 이메일 전송
    - 처리 완료 표시
6. 모든 작업이 클라이언트가 제출한 순서대로 실행됨

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

시스템 구성: 이벤트 저장소와 여러 서비스(주문, 재고, 결제 등)

시나리오:

1. 클라이언트가 주문 생성 요청
2. 시스템이 이벤트 "OrderCreated" 생성 및 저장:
    - {id: "event-1", type: "OrderCreated", data: {orderId: "O1", items: […], customerId: "C1"}, timestamp: t1}
3. 이벤트가 관련 서비스에 발행됨
4. 재고 서비스가 이벤트 수신 및 처리:
    - 재고 확인 및 할당
    - 이벤트 "InventoryAllocated" 생성 및 저장:
    - {id: "event-2", type: "InventoryAllocated", data: {orderId: "O1", items: […]}, timestamp: t2}
5. 결제 서비스가 "OrderCreated" 이벤트 수신 및 처리:
    - 결제 처리
    - 이벤트 "PaymentProcessed" 생성 및 저장:
    - {id: "event-3", type: "PaymentProcessed", data: {orderId: "O1", amount: 100}, timestamp: t3}
6. 주문 서비스가 "InventoryAllocated"와 "PaymentProcessed" 이벤트 수신:
    - 주문 상태 업데이트
    - 이벤트 "OrderCompleted" 생성 및 저장:
    - {id: "event-4", type: "OrderCompleted", data: {orderId: "O1"}, timestamp: t4}
7. 시스템 복구 시:
    - 저장된 모든 이벤트를 타임스탬프 순서대로 재생
    - 모든 서비스가 동일한 상태로 복원됨

 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

시스템 구성: ZooKeeper로 구현된 분산 세마포어와 여러 작업자 노드

시나리오:

1. 초기 상태: 세마포어 S = 1(이진 세마포어)
2. 작업자 W1이 연산 "x = x + 1" 실행 요청:
    - W1이 세마포어 S 획득 시도
    - 세마포어 획득 성공(S = 0)
    - W1이 현재 값 x = 5 읽기
    - W1이 연산 수행: x = 5 + 1 = 6
    - W1이 x = 6 쓰기
    - W1이 세마포어 해제(S = 1)
3. 작업자 W2가 연산 "y = x * 2" 실행 요청:
    - W2가 세마포어 S 획득 시도
    - 세마포어 획득 성공(S = 0)
    - W2가 현재 값 x = 6 읽기
    - W2가 연산 수행: y = 6 * 2 = 12
    - W2가 y = 12 쓰기
    - W2가 세마포어 해제(S = 1)
4. 작업자 W3가 연산 "x = x - 1" 실행 요청:
    - W3가 세마포어 S 획득 시도
    - 세마포어 획득 성공(S = 0)
    - W3가 현재 값 x = 6 읽기
    - W3가 연산 수행: x = 6 - 1 = 5
    - W3가 x = 5 쓰기
    - W3가 세마포어 해제(S = 1)
5. 결과적으로 연산들이 순차적으로 실행됨: x = 5, y = 12

1
2
3
4
5
6
7

[클라이언트 1] --- [순서 관리 계층] --- [복제된 데이터 노드 1]
     |                  |                     |
     |                  |                     |
[클라이언트 2] --- [합의 프로토콜] --- [복제된 데이터 노드 2]
     |                  |                     |
     |                  |                     |
[클라이언트 3] --- [동기화 메커니즘] --- [복제된 데이터 노드 3]

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

   [클라이언트 요청]
          |
          v
   [글로벌 시퀀서]
          |
          v
  [로컬 순서 관리자] <---> [동기화 프로토콜]
          |                    |
          v                    v
  [일관성 검사기] <---> [타임스탬핑 메커니즘]
          |
          v
   [응답 클라이언트]

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

[사용자 A]    [사용자 B]    [사용자 C]
    |             |             |
    v             v             v
[클라이언트 인터페이스]  [클라이언트 인터페이스]  [클라이언트 인터페이스]
    |             |             |
    v             v             v
   [이벤트 수집 레이어]
            |
            v
   [중앙 순서 관리자]
   /        |        \
  /         |         \
[데이터     [데이터     [데이터
 노드 1]     노드 2]     노드 3]
  \         |         /
   \        |        /
   [피드 생성 서비스]
   /        |        \
  /         |         \
[사용자 A   [사용자 B   [사용자 C
 피드]       피드]       피드]

1
2
3
4
5
6
7

[Client]
   │
   ▼
[연산 로그] ← 연산 순서 기록
   │
   ▼
[순서 관리 모듈] → 동기화 메커니즘