내가 벡터 시계에 대해 다음 읽고 있었다

Question

분산 시스템 클럭 : http://book.mixu.net/distsys/time.html

I 누락해야 뭔가. 네트워크 대기 시간 때문에 항상 "ack/nack"이 있습니까? 노드 B가 노드 C를 갱신하고 노드 B를 갱신중인 노드 C 메시지가 전송 중일 경우, 승인도 발생해야합니다.

Answer 1

아니요, ack/nack은 벡터 시계와 다른 레이어에 있습니다. ack/nack을 사용하여 패키지가 운송 레이어 (예 : TCP)를 통해 올바르게 전송/수신되었음을 확인합니다.

벡터 시계가 응용 프로그램 계층에 있습니다. 그들은 happened before 로직으로 메시지를 주문할 수 있도록합니다. 이는 예를 들어 데이터를 저장하고 복제/동기화 할 때 여러 시나리오에 해당됩니다.

일반적으로 분산 알고리즘에서 메시지를 비동기 적으로 보내고 결과를 업데이트하기 위해 직접 응답을 기대하지 않고 비동기 적으로 메시지를 보냅니다. 이러한 비동기 통신은 네트워크 오버 헤드를 줄이고 노드가 통신 할 수있는 속도와 처리량을 증가시킵니다.

동일한 데이터 세트 (문서)에서 작업하고 서로 업데이트하는 두 프로세스 (사람)를 상상해보십시오. 공정 A와 B를 시작 모두 0, A의 벡터 클록이 (0,0) 및 B의뿐만 아니라 (0,0) - 각각의 엔트리가있다 (A는 B)

1. A는 변경을하고 보낸다 B에 대한 업데이트
   • A : (1, 0); B : (0, 0)
2. B가 변화하게하고
   • A와 갱신 전송 : (1, 0); B : (0, 1)
3. A는 또 다른 변경을하고
   • 를 B로 갱신 전송 : (2, 0); B : (0, 1)
4. A가 B의 업데이 트를 수신하고 벡터 시계를보고
(0, 1)
• 편지 B 아직 문서에의 갱신 사항을 적용하지 않았다는 것을 알고 병합 할 데이터가 무엇인지 알아야합니다.
• A : (2, 1); B : (0, 1)
5. B는 서로 후 두 메시지의 수신과 유사 병합
   • 수행 할 필요가 (2, 1); B : (2, 1)

지금은 B가 다른 메시지를 전송하기 전에, 그것은 많은 시간을 낭비 것, 확인을 보낼 때까지 변경과 함께 기다릴 필요합니다. 그리고 결국에는 업데이트를 동시에 전송하고 병합해야하기 때문에 충돌이 있었거나 적어도 하나의 프로세스가 변경 사항을 철회해야했습니다.