GH GambleHub

합의 알고리즘

1) 합의가 무엇이며 왜 필요한가

합의-실패와 지연에 대해 여러 노드간에 동일한 값/시퀀스 값을 협상합니다. 전통적으로 상태 복제 문제 (State Machine Replication, SMR) 가 해결됩니다. 결정 론적 상태 머신과 일반적인 작업 순서가 있습니다.

구별:
  • 합의 (SMR): 단일 총 명령 순서 → 선형 가능 스토리지/레지스트리, 클러스터 메타 데이터, 트랜잭션 코디네이터.
  • 총 순서가없는 정족수 작업 (Dynamo와 같은, CRDT): 발산 및 후속 합병 허용; 글로벌 직렬화가 필요한 컨센서스를 대체하지 마십시오.

2) 시간 및 실패 모델

2. 1 회 모델

비동기 네트워크: 지연은 무제한입니다. FLP 정리는 추가 가정없이 안전성과 활력을 모두 보장하는 것이 불가능합니다.
부분적으로 동기화 (종종 실제로): 알 수없는 T 후에 시스템은 동기식으로 "동작" 합니다. 대부분의 알고리즘 (Raft, Paxos) 은 이에 의존합니다.
동기식: 채널에 대한 엄격한 시간 제한 (특수 네트워크/PRT를 제외한 판매는 거의 없음).

2. 2 실패 모델

충돌 내성 (CFT): 노드가 떨어지거나 매달릴 수 있지만 악의적으로 행동하지는 않습니다.
비잔틴 결함 내성 (BFT): 노드는 메시지를 거짓말/스푸핑 할 수 있습니다. f 비잔틴에 대한 내성을 위해서는 3f + 1 노트가 필요합니다.

3) 합의의 속성

안전: 일관성 (두 개의 올바른 노드는 다른 값을 해결하지 못함).
활력: 네트워크가 "건강" 하면 솔루션이 달성됩니다.
선형성 (선형성): 연산은 단일 순서로 원자로 "보입니다".
내구성: 결정이 롤백되지 않습니다 (로그/쿼럼 보호).

4) 정원, 다수 및 교차점

CFT 세계에서 클래식: 쿼럼> N/2. 기록과 지도자 선거는 쿼럼 교차점을 사용하므로 두 가지 "유효한" 작업은 충돌하지 않습니다.
BFT 세계에서: 쿼럼 2f + 1 중 3f + 1은 적어도 f + 1 정직한 노드의 교차점을 제공합니다.

교차 규칙: 두 쿼럼의 공통 공정 노드 (CFT) 또는 이하 f + 1 (BFT) 이 있어야합니다.

5) 상태 복제 (로그 + 응용 프로그램)

식별자 (색인/시대) 와 함께 로그에 명령이 추가됩니다. 원칙: "먼저 로그 항목 (커밋) 에 동의 한 다음 결정적으로 상태에 적용됩니다. "성장을 통제하려면 다음을 만드십시

스냅 샷 (초기 레코드를 삭제/컴파일 할 수있는 상태 조각).
저널 압축 및 로그 트리 엠.
결정 점검 (동일한 코드/설정 버전).

6) 리더십 및 비 리더십 제도

리더십 (Raft, Multi-Paxos, ZAB): 한 리더는 안정적인 리더에 대한 정신적, 운영 적으로 더 나은 대기 시간으로 레코드를 직렬화합니다.
리더리스/멀티 리더 (EPaxos, Caesar): 리더에 대한 더 많은 병렬 처리와 관용이지만 더 어려운 구현과 갈등 해결책; 팀의 작은 충돌로 이익이 보입니다.

7) 클래식 CFT 알고리즘

7. 1 Paxos/Multi-Paxos (및 실습)

아이디어: 두 단계 (준비/제안), 수용자의 약속, 대다수 정족수. Multi-Paxos는 "안정적인 리더" 를 남기고 "워밍업" 후 작업을 한 라운드 (새 항목의 경우) 로 전환합니다.

특징:
  • 유연하지만 구현하기 어렵습니다.
  • 특별 항목 (공동 합의) 을 통한 재구성.
  • 실제로 라이브러리/엔진 (Chubby/Spanner 생성).

7. 2 뗏목

학습을 위해 분해됨: 리더 선택, 로그 복제, 재구성.

선거: 임의의 타임 아웃, 용어 투표; 학기당 한 명의 리더.
AppendEntries: 리더는 레코드를 스트리밍하고 접두사 (인덱스/용어) 의 일치를 모니터링하며 다수의 고정을 위해 노력합니다.
읽기 경로: 임대 판독 (강력한 리더와 함께) 또는 선형 판독에 대한 판독 색인.
정찰: "공동" - 노드는 전환하기 전에 두 클러스터로 투표합니다.

장점: 개발하기 쉬운/디버그, 강력한 차수 불변량. 단점: 리더는 압력 포인트입니다.

7. 3 ZAB (ZooKeeper Atomic Broadcast )/뷰 스탬프 복제 (VRR)

ZAB: 리더가 트랜잭션, 복구 단계, zxid (epoch + 인덱스) 를 방송합니다.
VRR: Multi-Paxos와 비슷한 주요 복제품으로 "보기".

8) 비 리더/멀티 리더 CFT

8. 1 EPaxos

영구 리더는 없습니다. 모든 노드에서 명령을 시작할 수 있습니다.
갈등 팀은 부분 주문을받습니다. 충돌없이-로컬로 1-2 RTT에 전념하십시오.
충돌이 적지 만 복잡한 종속성/그래프 코드로 지리 분포가 증가합니다.

8. 2 시저, 멘 시우스

대기 시간/밸런싱 및 WAN 작동을 최적화하는 변형.

9) BFT 알고리즘 및 PoS 제품군

9. 1 PBFT (실제 BFT)

3 단계 (사전 준비/준비/커밋) 에는 3f + 1 노드가 필요합니다.
로컬 네트워크, 다단계 도로 및 O (N ²) 메시지의 대기 시간이 짧습니다.

9. 2 텐더 민트 (BFT-PoS 스타일)

제안과 2 표의 라운드 (방지/사전 커밋).
결정 론적 검증 자 제안자, 타임 아웃, 부분 동기성.
수십/수백 개의 유효성 검사기가있는 허용/PoS 네트워크에 적합합니다.

9. 3 HotStuff (및 파생 상품)

3 상 체계는 쿼럼 인증서 (QC) 와 함께 "패키지" 로 통합됩니다.
통신의 선형 복잡성, 패키징 지원 및 병렬 파이프 라이닝은 블록 체인 구현 (예: Diem/Move 생태계) 에 편리합니다.
임계 값 서명으로 트래픽이 줄어 듭니다.

9. 4 PoW/누적 합의 (간단히 말해)

엄격한 의미에서 BFT가 아니라 확률 적 수렴 (가장 많은 작업을 수행하는 체인). 장점: 단순성/개방성; 단점: 에너지, ~ 초 단위.

10) 읽기: 선형, 순차적 및 캐시

선형 읽기: 활성 임대 또는 읽기 색인 (Raft) → 쿼럼을 통한 확인을 통한 리더.
순차적: 신선도를 보장하지 않고 모든 노드에서 읽을 수 있습니다.
추종자 읽기: 약한 요구 사항에 따라 허용 가능; 캐시를 위해-좋아.

11) 재구성 (클러스터 구성 변경)

두 가지 겹치는 구성 (공동 합의) 이 필요합니다. 모든 커밋은 "홀" 이없는 두 구성의 쿼럼을 통과합니다.
한 번에 하나를 추가/제거하고 쿼럼 크기를 관찰하십시오.
리더십 전송은 일시 중지를 줄입니다.

12) 성능 및 튜닝

12. 1 지연

리더십 알고리즘: 쓰기 당 1 RTT (안정적인 리더 포함) + 복제.
지리적 분포: WAN RTT는 → 지역 지역 + 교차 지역 복제 또는 EPaxos/HotStuff 접근 방식을 사용합니다.

12. 2 처리량

배칭 (명령 그룹), 병렬 AppendEntries, 로그 페이지 캐시, 병렬 응용 프로그램 (작업이 전환 될 때).
디스크: 별도의 장치 인 'O _ DIRECT '/AIO의 NVMe/Log, SLA 제한 (내구성/대기 시간 손상) 이있는 큰' fsync '간격.

12. 3 p99 꼬리

뜨거운 매듭을 피하십시오 (항상 하나의 리더가 있습니다): 팔로어의주기적인 회전 또는 읽기 오프로드

모니터 GC 일시 정지 (JVM/Go), CPU 핀, NUMA.

13) 지리 및 토폴로지

1 개 영역, 3 개 영역: 클래식 CFT 클러스터 (N = 3/5).
2 개 영역: 피하십시오-1-1 분할에서 신뢰할 수있는 쿼럼이 없습니다.
3 개 이상의 영역: "중간" 또는 리더리스 알고리즘의 리더; 비동기 로그가있는 지역 프록시/로컬 전선이 가능합니다.

14) 실제 운영 문제

14. 스냅 샷 및 복구 1 개

저널 크기/트랜잭션 수에 따른 임계 값.
스냅 샷을 새 노드로 전송; 체크섬 확인.

14. 2 모니터링

리더십: 누가 리더이며 얼마나 많은 용어 (용어/시대) 가 바뀌 었습니까?

(PHP 3 = 3.0.6, PHP 4)

정원 건강: "대다수가 살아 있습니까/2f + 1입니까?"

로그 크기/압축 속도, 스냅 샷 대기열.

BFT: 투표 점유율, 덤프 서명국, QC 지연

14. 3 코드 보안/일관성

와이어에서 프로토콜 버전을 변경하고 로그 호환성으로 마이그레이션합니다

외부 효과에 대한 펜싱 토큰 ("분산 잠금" 참조): CRON/작업으로 전송하는 리드 타임 (용어).

15) 반 패턴

직렬화없이 하나의 DBMS 또는 쿼럼을 읽는 것으로 충분한 "패션을 위해" 합의를하십시오.
명확한 경계 (CAP) 없이 CP와 AP 혼합 → 예측할 수없는 UX.
수십 개의 노드 (어려운/비싼) 가있는 엔터프라이즈 작업에 대한 PoW/PoS를 과대 평가하십시오.
구성이 변경 될 때 재구성 및 "교차 쿼럼" 을 무시하십시오.
읽기 장벽 부족 (임대/읽기 색인) → 더러운 읽기.
2 노드 클러스터를 실행하십시오 (대부분 없음).
디스크를 과소 평가하고 fsync: "모든 것이 메모리로 날아갑니다" -첫 번째 재부팅까지.

16) 선택 점검표

1. 실패 모델: CFT (충돌) 또는 BFT (악성)?
2. 지리: 한 지역/3 지역 또는 WAN? RTT가 결정합니다.
3. 독서 의미론: 선형 판독 값이 필요합니까? 임대/판독 색인/후속 조치.
4. 하중: p50/p99에 의한 기대, 처리량; 다중 리더십이 필요한지 여부.
5. 운영 복잡성: 라이브러리/상용 엔진 (etcd/ZK/Consul/Raft-libs) vs 기본 구현.
6. 재구성: 빈번한가? 공동 합의와 마이그레이션 도구가 필요합니다.
7. 통합: 외부 부작용-신기/용어로 펜싱이 있습니까?
8. 보안: 호스트 인증, 채널 암호화, 프로토콜 버전 제어.
9. 테스트 플레이 북: 파티션, GC 스톱, 킬 리더, 느린 디스크, 시계 왜곡.
10. 관찰 가능성: 리더/래그/저널 및 경보 메트릭이 설정되었습니다.

17) 미니 가이드: 언제 가져갈 것인가

DC 내에서 구성/잠금/조정을위한 etcd/Raft 클러스터.
ZK (구 스택, 대기열, 리더십) 와 이미 연결된 서비스에 대한 ZooKeeper/ZAB.
고도로 전문화 된 시스템의 기성품 서비스/라이브러리를 통한 다중 Paxos.
지리 분포 및 낮은 명령 충돌을위한 EPaxos.
수십 ~ 수백 개의 유효성 검사기 및 최종 요구 사항이있는 허용 네트워크/PoS 계층 용 Tendermint/HotStuff.
컨센서스가 필요하지 않은 경우 Dynamo와 유사한/CRDT이지만 후속 합병에 대한 접근성/스케일이 중요합니다.

18) 인터페이스의 예 (의사)

18. 1 Commit 레코드 (래프트 스타일)

pseudo client -> leader: Propose(cmd)
leader. appendLog(cmd)
leader. replicateToQuorum()
if quorum_acked:
leader. commit(index)
leader. apply(index)
leader. reply(client, ok)

18. 2 선형 판독을위한 판독 색인 (Raft)

pseudo client -> any: LinearizableRead node -> leader: ReadIndex?
leader -> quorum: Heartbeat (barrier)
leader -> node: ReadIndex=commit_index node. wait_until(applied_index >= ReadIndex)
node. reply(client, state_at(ReadIndex))

18. 3 공동 설정

pseudo old_conf + new_conf # quorums must intersect commit (entries under joint)
switch_to(new_conf)

18. 4 BFT (대략 HotStuff)

pseudo propose(block)
collect votes -> QC lock on highest QC commit when have consecutive QCs across phases

19) FAQ

Q: 왜 두 매듭과 타이 브레이커를 사용하지 않습니까?
A: 세 번째 중재자가없는 두 개의 노드는 분할에서 정족수를 제공하지 않습니다. 3 (CFT) 또는 3f + 1 (BFT) 이 필요합니다.

Q: 뗏목 "간단한" Paxos는 무엇입니까?
A: 명확한 분해, 로그 및 구성의 이해할 수없는 불변; 구현 및 유지 관리가 더 쉽습니다.

Q: 리더를로드하지 않고 어떻게 빨리 읽습니까?
A: 비 임계 값에 대한 추종자 판독 (연속) 또는 선형에 대한 임대 판독/판독 색인; 캐시.

Q: p99를 죽이는 것은 무엇입니까?
A: WAN-RTT, 디스크 fsync, GC- 스톱, 과열 된 리더, 출퇴근 시간에 큰 스냅 샷.

Q: 캐시/카탈로그에 합의가 필요합니까?
A: 충분한 최종 일관성이 있다면-아니요. 거래 불변량이 필요한 경우 예.

20) 총계

합의는 엄격한 일관성과 주문을위한 도구입니다. 실패 모델과 지리를 기반으로 알고리즘을 선택하십시오. 쿼럼 교차, 올바른 재구성, 선형 읽기 및 관찰 가능성을 제공합니다. 외부 효과, 스냅 샷 및 잡지 분야에 대한 펜싱을 잊지 마십시오. 그런 다음 상태 복제를 예측할 수 있으며 사건은 드물고 이해할 수 있습니다.

Contact

문의하기

질문이나 지원이 필요하시면 언제든지 연락하십시오.우리는 항상 도울 준비가 되어 있습니다!

통합 시작

Email — 필수. Telegram 또는 WhatsApp — 선택 사항.

이름 선택 사항
Email 선택 사항
제목 선택 사항
메시지 선택 사항
Telegram 선택 사항
@
Telegram을 입력하시면 Email과 함께 Telegram에서도 답변드립니다.
WhatsApp 선택 사항
형식: +국가 코드 + 번호 (예: +82XXXXXXXXX).

버튼을 클릭하면 데이터 처리에 동의하는 것으로 간주됩니다.