사육사 연구 노트 (B) - 내부 원칙

사육사 연구 노트 (B) - 내부 원칙

노드 1 사육사의 유형

일반적으로 단기 및 장기 지속 형 유형으로 나눌 수 있습니다, 주요 차이점은 다음과 같습니다 :

• 영구 : 클라이언트와 서버가 분리 된 후, 생성 된 노드가 삭제되지 않습니다;
  • 디렉토리 노드 지속성 : 사육사에서 클라이언트 연결 해제 후, 노드가 여전히 존재한다;
  • 영구 일련 번호 디렉토리 노드 : 클라이언트 후 사육사는 노드가 여전히 존재한다, 연결되어 있지만, 순차적으로 번호가 사육사 노드 이름을 줄 것이다;
• 개요 : 클라이언트와 서버 연결이 해제 된 후, 노드는 자신의 삭제를 만들 수 있습니다
  • 임시 디렉토리 노드 : 사육사에서 클라이언트 연결 해제 후, 노드는 삭제됩니다;
  • 임시 순차적으로 번호가 노드 : 클라이언트 후 사육사는 노드가 제거되고, 분리되어 있지만, 노드 이름에 사육사가 순차적으로 번호가 매겨집니다.

설명하기 위해 작성하는 것입니다 znode로고를 설정하는 시간에 순서를 znode첨부합니다 뒤에 이름이 부모에 의해 유지되는 값, 단지 일정하게 증가하는 시퀀스 번호 카운터.

그 고객은 일련 번호에 의해 사건의 추론 순서가 될 수 있도록 분산 시스템에서, 시퀀스 번호는 글로벌 주문에 대한 모든 이벤트에 사용할 수 있습니다.

2. 통계 구조

1) 트랜잭션 zxid 노드를 생성 czxid- 각 변형 사육사 상태 사육사 트랜잭션 ID 인 타임 스탬프의 형태 zxid를 수신한다. 총 트랜잭션 ID는 모든 사육사 위해 수정됩니다. zxid1 미만 zxid2는 다음 zxid2 전에 발생 zxid1 경우 수정할 때마다, 독특한 zxid 있습니다.
2) ctime이 - (+) 1970 년부터 생성 될 znode 밀리 초
) 3 mzxid - 최종 갱신 트랜잭션 zxid znode
znode 마지막 수정 밀리 초 (1970 년 이후) - 4)에 mtime
최근 업데이트 5) pZxid-znode을 자식 노드는 zxid
znode 아이 노드 번호 수정 znode 아이 노드 번호 변경 - 6) cversion를
znode 데이터 변경 호 - 7) dataversion
aclVersion 8) - znode 액세스 제어 목록 변경 번호
노드가 일시적이면 9) ephemeralOwner-, 이것은 znode 유무 인 세션의 ID입니다. 비 임시 노드는 0 인 경우.
데이터 길이 10)의 dataLength- znode
11) NUMCHILDREN - 자식 노드의 znode의 수

3. 리스너 원칙 (하이라이트)

우리가 전에 배운 전에, 노드 변경, 사육사가 클라이언트에 통보됩니다 노드를 기울인다는 그것의 관심 고객으로 등록 사육사. 각 노드의 분산 시스템의 작동 상태를 통합하기 위해 주로 사육사, 노드가 알고 각 노드에 제공하는 리소스 충돌 선점의 경우 자원의 제공을 조정하는 방법 클러스터의 전반적인 상태. 모든 구현은에서 사육사에 의존하는 이벤트 리스너 및 알림 메커니즘 .

일반 원칙 다음을 유지 사육사 watchList의 변화가 발생하면 관찰자의 노드의 객체 인은, 그것은 통과합니다 watchList, 하나의 통지 그들에 의해 하나.

사육사 비동기 통신 원리의 코드 모양을 추적하여 :

• 첫째, 코드는 실행을 만들 때 Zookeeper목표
  

• 에 코드 Zookeeper()방법은, 당신은 자신의 통화 다른 생성자에 있음을 볼 수있다 :
  

• 후속 계속 : 두 개의 스레드, 비동기 클라이언트와 서버 통신 사육사를 생성하는이 방법은 비동기, 자식 스레드가 있어야합니다
  

• 이러한 두 가지 Thread의 서브 클래스
  

• 생성 된 원래 생성에 ClientCnxn있어서 아래 개시 방법이있다 :
  

• 내부 계속 :
  

~ 확인이에 우리는 분명 우리가 만들고있는 것을 볼 수 있습니다 Zookeeper때 두 개의 하위 스레드 객체를 생성, sendTread및eventThread

요약 : 모든 요청에 의해 등록 된 sendThread서버로 전송하고, eventThread통지 서비스의 끝을 기다리고, 통지를 받으면, 콜백에 갔다 Process()방법.

작은 밤의 이미지 :

sendThread라는 두 젊은 비서와 상사가 다른이 eventThread이라고합니다. 하루는 ~ eventThread B 사장의 답변을 기다리는 동안이 응답을 수신하면, 상사에게 작업이 될 것입니다 보스의 메시지를 수행하는 보스 B 메시지, 다음 sendThread 작은 장관을주고, 보스 알려갔습니다.

4. ZAB 이론 사육사의 (키)

사육사는 어떻게 읽기 및 쓰기 데이터는 높은 동시성에서 질서 정연하고 전 세계적으로 일관된 분산 보장하는 것입니다?

으로 ZAB의 사육사 원자 방송, 즉 방송 사육사 원자 : 보장 프로토콜입니다.

주요 내용은 두 부분이다 : ① 더 리더 선거 리더] [충돌 복구, ② 리더가 정상 작동을 시작하지 [읽기]

그런 다음 논의는 어떻게 ~ 어떻게 지도자 선거 후 리더와 함께 작동합니다

4.1 선거 메커니즘

4.1.1 사육사 클러스터 노드 상태 :

• 상대 : 모든 노드 상태 클러스터 찾을 때 바로 시작 리더 상태를 찾고있다 . 상태는 서비스를 제공 할 수 없습니다, 다른 국가가 될 수 있습니다.
• Abserving : 신속 추종자 투표 기록이있는 작은 지역 지도자 클러스터를 확장하기 위해, 성공적인 투표 후 쓰기에 관찰자에게 통지하기 위해 확장 된 클러스터 성능의 서면 그. [적용 장면 : 큰 클러스터, 데이터 센터에서]
• 다음 : 추종자
• 선도 : 리더

1) 반 메커니즘 : 클러스터 시스템의 절반이 생존을 위해 더 이상 클러스터 사용할 수 있습니다. 따라서, 설치 홀수 사육사 서버.

2) 사육사는 아니지만 구성 파일에 마스터 및 슬레이브를 지정했습니다. 그러나 사육사의 작업, 리더에 대한 노드가 다른 사람들이 추종자는, 리더 선거 메커니즘은 내부 일시적하는 것입니다.

3) 단순 예에 선거의 전 과정을 도시한다.

그들은 최신 상태로있는 동안 자신의 1-5 시작에서 5 개 클러스터 사육사의 서버, ID가 데이터의 양을 저장하기 위해이 시점에서 역사적 데이터 없다는 것을, 존재한다고 가정하는 것은 동일합니다. 이러한 서버가 같이 어떻게되는지 시동 순차적한다고 가정.

(1) 서버 1 시작은, 선거를 시작합니다. 1 개 서버 뻔뻔는 투표를. 이 때, 절반 이상 (3 표) 충분히 서버 1 표, 한 표가 선거는 서버 한 상태 남아 찾고, 완료 할 수 없습니다;

다음 (2) 서버 (2) 시작, 그리고 선거를 시작합니다. 서버 1과 2는 각각 투표 용지 및 정보 교환에 자신의 투표를 : 2 (서버 1) 선출 현재 투표보다 큰이 시점 1 개 서버 검색 서버 ID에서 서버 (2)을 선출하기 위해 투표 용지를 변경합니다. 이 시간, 1 추천 수 0 표, 서버 2 표 2 표, 아니 절반 이상이 결과, 선거 완료 할 수없는 서버에서 상태 남아 서버 1, 2를 찾고

(3) 3 서버 시작은, 선거를 시작했다. 이 때, 서버 1과 2는 서버 (3)을 변경 투표 할 것이다. 투표 결과 : 1 개 서버 0 표, 0 투표 2 서버, 서버 3 (3) 표. 이 시점에서 서버가 3, 서버 (3) 선출 된 리더의 절반 이상이 투표있다. 1,2- 서버 상태 3 서버의 상태 변화를 이끌어 다음 변경;

(4) 4 서버 시작은, 선거를 시작했다. 서버가 1,2,3 상태를 찾고 있지 않습니다이 경우, 투표 정보를 변경하지 않습니다. 정보 교환 투표 결과 : 3 세 티켓 서버, 서버 4 투표 1. 이 때, 대부분의 서버 (4)는, 투표는 서버 (3)에 정보를 변경하고, 다음 상태를 변경하려면,

(5) 5 서버는 4 때 동생처럼 시작한다.

참고 : 첫 번째 선거 리더 zxid (데이터 버전)를 비교하면, 다음 대한 myid 비교 .

4.2 기록 데이터 흐름

1) 서버 1 사육사 상 클라이언트 기록 데이터는 기록 요청을 전송한다.
서버 1은 리더가 아닌 경우 사육사 서버의 각 리더가 있기 때문에 2), 다음 서버 1은 리더로 전달 추가 요청을 받게됩니다. 리더는 같은 서버 1과 서버 2로, 각 서버는 큐가 기록되는 가입 요청을 쓸 것, 각각의 쓰기 요청 서버에 방송하고, 리더가 성공적으로 정보를 전송됩니다.
3) 리더는 쓰기 작업을 수행 할 수 있음을 나타냅니다 성공적으로 절반 서버 정보보다 더 받았을 때. 리더는 쓰기 요청이 성공에 쓰기 큐를 구현하는 각 서버의 정보를 수신 한 후, 제출 된 각 서버 정보로 전송됩니다.
4) 서버 1 추후 공지가 클라이언트 데이터 쓰기는 당신이 믿는, 성공적으로 전체 쓰기 작업의 성공이.