zookeeper 3.3.3 소스 코드 분석 (1) 작업 원리 개술

간단하게 zookeeper 가 일 하 는 과정 을 말 해 보 세 요. 만약 에 이 과정 에 대해 잘 모 르 거나 어떻게 사용 하 는 지 등에 대해 잘 모 르 면 다른 글 을 참고 하 세 요. 예 를 들 어 이 일련의 글 은 어떻게 사용 하 는 지 설명 하지 않 을 것 입 니 다.
zookeeper 는 두 가지 작업 모델 이 있 는데 하 나 는 단기 방식 이 고 다른 하 나 는 클 러 스 터 방식 이다. 단기 방식 은 여기 서 분석 하 는 범주 에 속 하지 않 는 다. 왜냐하면 zookeeper 를 연구 하 는 목적 은 바로 zookeeper 클 러 스 터 의 기계 가 어떻게 조 화 롭 게 작업 하 는 지 연구 하 는 데 있 기 때문이다.
zookeeper 몇 대 를 설정 하려 면 같은 설정 파일 을 사용 해 야 합 니 다. 설정 파일 에 일부 설정 항목 이 있 지만 클 러 스 터 와 관련 된 것 은 이 항목 입 니 다.
server.1=192.168.211.1:2888:3888
server.2=192.168.211.2:2888:3888
두 서버 의 설정 을 정의 합 니 다. 형식 은
server.serverid=serverhost:leader_listent_port:quorum_port
이름 그대로 server id 는 본 서버 의 id, leader 입 니 다.listen_port 는 이 서버 가 leader 가 되면 감청 해 야 할 포트 로 follower 로부터 요청 을 받 을 수 있 습 니 다. quorumport 는 클 러 스 터 의 모든 서버 가 leader 를 처음 선거 할 때 감청 하 는 포트 로 서버 간 통신 선거 leader 에 사용 된다.
주의해 야 할 것 은 server id 는 이 프로필 에 쓰 여 있 지 않 고 datadir 의 my id 파일 에 지정 되 어 있 습 니 다. 모든 서버 가 하나의 프로필 을 통일 적 으로 사용 하 는 것 이 목적 입 니 다. 이 프로필 에는 특정 서버 와 관련 된 정보 가 없습니다. 이렇게 하면 서 비 스 를 발표 할 때 오류 가 발생 하지 않 습 니 다.이 server id 값 을 저장 하 는 파일 을 독립 적 으로 만 듭 니 다.
zookeeper 클 러 스 터 작업 의 과정 은 다음 과 같은 몇 가지 단 계 를 포함한다. 1) recovery. 이 과정 은 클 러 스 터 서버 의 시작 과 복 구 를 말 합 니 다. 복 구 는 다른 차원 의 '시작' 으로 이해 할 수 있 기 때 문 입 니 다. - 역사 데이터 의 시작 을 복원 해 야 합 니 다. 그 다음 에 상세 하 게 설명 할 것 입 니 다. 2) broadcast. 이것 은 시작 이 끝 난 후에 클 라 이언 트 의 연결 을 받 아 함께 작업 하 는 과정 입 니 다.클 라 이언 트 가 데 이 터 를 수정 하 는 변경 사항 이 있 으 면 반드시 leader 가 follower 에 게 방송 하기 때문에 'broadcast' 라 고 부 릅 니 다.
전개 하면 zookeeper 클 러 스 터 는 대개 이렇게 작 동 합 니 다. 1) 먼저 모든 서버 에서 프로필 과 데이터 파일 을 읽 고 server id 에 따라 이 컴퓨터 에 대응 하 는 설정 (바로 앞 에 있 는 주소 와 포트) 을 알 고 역사 데 이 터 를 메모리 에 불 러 옵 니 다. 2) 클 러 스 터 의 서버 는 앞에서 제 시 된 quorum port 감청 클 러 스 터 의 다른 서버 요청 에 따라 시작 합 니 다.또한 자신 이 선출 한 leader 도 다른 서버 에 알 리 고 여러 번 왔 다 갔다 하 며 클 러 스 터 를 선출 하 는 leader. 3) leader 를 선출 한 것 은 진정한 의미 의 'leader' 가 아니다. 여기 서 leader 는 클 러 스 터 의 다른 서버 와 데 이 터 를 동기 화 해 야 하기 때문이다. 이 단계 가 잘못 되면 2) 에서 leader 를 다시 선출 할 것 이다. leader 선거 가 끝 난 후에클 러 스 터 에 있 는 다른 서버 를 'follower' 라 고 부 릅 니 다. 즉, leader 의 명령 을 따라 야 합 니 다. 4) 클 러 스 터 에 있 는 모든 서버 는 leader 든 follower 든 모두 데이터 가 일치 합 니 다. 클 라 이언 트 의 연결 을 받 을 수 있 습 니 다. 읽 기 형식의 요청 이 라면 데 이 터 를 바 꾸 지 않 기 때 문 입 니 다.그렇지 않 으 면 리더 에 게 보고 해 야 하 는데 리더 에 게 어떻게 알려 야 합 니까?바로 앞에서 말 한 leaderlisten_port. leader 는 이 수정 데이터 요청 을 받 은 후에 클 라 이언 트 의 다른 follower 에 게 방송 할 것 입 니 다. 절반 이 넘 는 follower 가 답장 을 하면 이 수정 작업 에 해당 합 니 다. 이때 leader 는 이전 서버 에 클 라 이언 트 에 게 응답 할 수 있다 는 것 을 알려 줄 수 있 습 니 다. 위 1), 2), 3) 대응 하 는 recovery 과정 을 볼 수 있 습 니 다. 4) 대응 하 는 broadcast 과정 을 볼 수 있 습 니 다.