[추천컬렉션] 영혼의 고문! 사육사의 31발 대포

Zookeeper 핵심 지식 요약

제목을 읽어주세요

1. ZooKeeper란 무엇인가요?
2. ZooKeeper는 무엇을 제공하나요?
3. Zookeeper 파일 시스템
4. Zookeeper는 마스터 노드와 슬레이브 노드의 상태가 동기화되도록 어떻게 보장합니까?
5. 4가지 유형의 데이터 노드 Znode
6. Zookeeper Watcher 메커니즘 - 데이터 변경 알림
7. 클라이언트 등록 Watcher는 어떻게 구현되나요?
8. Watcher의 서버측 처리를 구현하는 방법은 무엇입니까?
9. 클라이언트가 Watcher를 어떻게 다시 호출하나요?
10. ACL 권한 제어 메커니즘에 대해 잘 알고 계십니까?
11. Chroot 기능에 대해 알고 계시나요?
12. 세션 관리에 대해 잘 알고 계시나요?
13. 서버의 역할은 무엇인가요?
14. Zookeeper
15. 서버 작동 상태 데이터는 어떻게 동기화되나요?
16. 주키퍼는 거래의 순차적 일관성을 어떻게 보장하나요?
17. 분산 클러스터에 마스터 노드가 있는 이유는 무엇인가요?
18. zk 노드 가동 중지 시간을 처리하는 방법은 무엇입니까?
19. 주키퍼 로드 밸런싱과 nginx 로드 밸런싱의 차이점
20. 주키퍼 배포 모드는 무엇인가요?
21. 클러스터에 필요한 최소 머신 수는 어떻게 되나요? 클러스터에 서버가 3개 있는데, 노드 중 하나가 다운되었습니다. 이때도 Zookeeper를 사용할 수 있나요?
22. 클러스터는 동적 머신 추가를 지원하나요?
23. Zookeeper의 노드 감시 알림은 영구적인가요? 영구적이지 않은 이유는 무엇입니까?
24. Zookeeper의 Java 클라이언트는 무엇입니까?
25. 통통이란 무엇이며 사육사와 비교하면 어떻다고 생각하시나요?
26. 사육사에서 일반적으로 사용되는 몇 가지 명령에 대해 이야기해 보겠습니다.
27. ZAB와 Paxos 알고리즘의 연결과 차이점은 무엇인가요?
28. 주키퍼의 일반적인 응용 시나리오
29. 주키퍼에는 어떤 기능이 있나요?
30. Zookeeper의 알림 메커니즘에 대해 알려주세요.
31. 주키퍼와 더보의 관계?

몇 개나 답할 수 있나요?

1. ZooKeeper란 무엇인가요?

ZooKeeper는 오픈 소스 분산 조정 서비스입니다. 분산 애플리케이션에 일관성 서비스를 제공하는 소프트웨어입니다. 분산 애플리케이션은 데이터 게시/구독, 로드 밸런싱, 이름 지정 서비스, 분산 조정/알림, 클러스터 관리, 마스터 선택, 분산 잠금 및 분산 대기열 및 기타 기능을 구현할 수 있습니다.

ZooKeeper의 목표는 복잡하고 오류가 발생하기 쉬운 핵심 서비스를 캡슐화하여 사용자에게 간단하고 사용하기 쉬운 인터페이스와 효율적인 성능과 안정적인 기능을 갖춘 시스템을 제공하는 것입니다.

Zookeeper는 다음과 같은 분산 일관성 기능을 보장합니다. 일관성)

• 클라이언트의 읽기 요청은 클러스터의 모든 머신에서 처리될 수 있습니다. 읽기 요청에 노드에 등록된 리스너가 있으면 연결된 Zookeeper 머신에서도 이 리스너를 처리합니다. 쓰기 요청의 경우 이러한 요청은 동시에 다른 사육사 컴퓨터로 전송되며 합의에 도달한 후에만 요청이 성공적으로 반환됩니다. 따라서 Zookeeper 클러스터 시스템 수가 증가하면 읽기 요청 처리량은 증가하지만 쓰기 요청 처리량은 감소합니다.
주문은 Zookeeper에서 매우 중요한 기능입니다. 모든 업데이트는 전역적으로 주문됩니다. 각 업데이트에는 고유한 타임스탬프가 있습니다. 읽기 요청은 업데이트와 관련된 순서로만 이루어집니다. 즉, 읽기 요청의 반환 결과에는 사육사의 최신 zxid가 포함됩니다.

• 2. ZooKeeper는 무엇을 제공하나요?

  • 파일 시스템
  • 알림 메커니즘

  3. Zookeeper 파일 시스템

  Zookeeper는 다중 레벨 노드 네임스페이스를 제공합니다(노드는 znode라고 함). ). 파일 시스템과 달리 이러한 노드는 관련 데이터를 설정할 수 있습니다. 파일 시스템에서는 파일 노드만 데이터를 저장할 수 있지만 디렉터리 노드는 저장할 수 없습니다. 팔로우"인터뷰 칼럼"을 팔로우하시면 더 많은 인터뷰건조한 정보를 보실 수 있습니다.

  높은 처리량과 낮은 대기 시간을 보장하기 위해 Zookeeper는 메모리에 이러한 트리형 디렉터리 구조를 유지합니다. 이 기능으로 인해 Zookeeper는 각 노드의 데이터 저장 상한이 1M입니다.

  4. Zookeeper는 마스터 노드와 슬레이브 노드의 상태 동기화를 어떻게 보장합니까?

  Zookeeper의 핵심은 서버 간 동기화를 보장하는 원자 브로드캐스트 메커니즘입니다. 이 메커니즘을 구현하는 프로토콜을 Zab 프로토콜이라고 합니다. Zab 프로토콜에는 복구 모드와 브로드캐스트 모드라는 두 가지 모드가 있습니다.

  • 복구 모드

  서비스가 시작되거나 리더가 충돌한 후 Zab은 리더가 선택되고 대부분의 서버가 리더와의 상태 동기화를 완료하면 복구 모드가 종료됩니다. 상태 동기화는 리더와 서버가 동일한 시스템 상태를 갖도록 보장합니다.

  • 브로드캐스트 모드

  리더가 다수의 팔로워와 상태를 동기화하면 메시지 브로드캐스트를 시작할 수 있습니다. 즉, 브로드캐스트 상태로 들어갑니다. 이때 서버가 ZooKeeper 서비스에 참여하면 복구 모드로 시작되어 리더를 검색하고 상태를 리더와 동기화합니다. 동기화가 완료되면 메시지 브로드캐스팅에도 참여합니다. ZooKeeper 서비스는 리더가 충돌하거나 리더가 대부분의 팔로어 지원을 잃을 때까지 브로드캐스트 상태로 유지됩니다.

  5. Zookeeper에 어떤 데이터 노드가 있는지 이야기해 보겠습니다. EPHE MERAL - 임시 node

  임시 노드의 수명 주기는 클라이언트 세션에 바인딩됩니다. 클라이언트 세션이 만료되면(클라이언트와 Zookeeper 간의 연결이 끊어졌다고 해서 반드시 세션이 만료되는 것은 아닙니다), 이 클라이언트가 생성한 모든 임시 노드는 제거됩니다.
  • PERSISTENT_SEQUENTIAL - 영구 순차 노드
  순차 속성이 추가된다는 점을 제외하면 기본 기능은 영구 노드와 동일합니다. 상위 노드에 의해 유지되는 자동 증가 정수가 추가됩니다. 노드 이름.
  • EPHEMERAL_SEQUENTIAL - 임시 순차 노드
  기본 기능은 임시 노드와 동일하며, 상위 노드에 의해 유지되는 자동 증가 정수가 노드 이름에 추가됩니다.

  6. Zookeeper Watcher 메커니즘에 대해 이야기해 보겠습니다.

  Zookeeper를 사용하면 서버의 일부 지정된 이벤트가 이 Watcher를 트리거하면 서버에서 메시지를 보낼 수 있습니다. 지정된 클라이언트에 이벤트 알림을 사용하여 분산 알림 기능을 구현한 후 클라이언트는 Watcher 알림 상태 및 이벤트 유형에 따라 비즈니스를 변경합니다. "인터뷰 칼럼"을 팔로우하시면 더 많은 인터뷰 꿀팁을 얻으실 수 있습니다.

  작업 메커니즘:

  (1) 클라이언트 등록 감시자

  (2) 서버 프로세스 감시자

  (3) 클라이언트 콜백 감시자

  Watcher 기능 요약:

  (1) 일회성

  상관없습니다. 서비스 클라이언트이든 클라이언트이든 Watcher가 트리거되면 Zookeeper는 이를 해당 저장소에서 제거합니다. 이 설계는 서버에 대한 부담을 효과적으로 줄여줍니다. 그렇지 않으면 매우 자주 업데이트되는 노드의 경우 서버가 지속적으로 클라이언트에 이벤트 알림을 보내므로 네트워크와 서버 모두에 큰 부담이 됩니다.

  (2) 클라이언트 직렬 실행

  클라이언트 Watcher 콜백 프로세스는 직렬 동기화 프로세스입니다.

  (3) 경량

  3.1. 감시자 알림은 매우 간단합니다. 클라이언트에게 이벤트가 발생했음을 알리기만 하고 이벤트의 구체적인 내용을 설명하지는 않습니다.

  3.2 클라이언트가 감시자를 서버에 등록하면 클라이언트의 실제 감시자 개체 엔터티가 서버에 전달되지 않습니다. 클라이언트 요청에는 부울 유형 속성만 표시됩니다.

  (4) 감시자 이벤트가 비동기적으로 전송됩니다.

  감시자 알림 이벤트가 서버에서 클라이언트로 비동기적으로 전송됩니다. 이로 인해 서로 다른 클라이언트와 서버가 소켓을 통해 통신하는데, 이는 네트워크 지연이나 기타 요인으로 인해 발생할 수 있습니다. Zookeeper 자체가 순서 보장을 제공하기 때문에 클라이언트는 사용할 수 없는 시간에 이벤트를 모니터링합니다. 즉, 클라이언트가 이벤트를 모니터링한 후에만 모니터링하는 znode의 변경 사항을 인식합니다. 따라서 Zookeeper를 사용할 때 노드의 모든 변경 사항을 모니터링할 수 있다고 기대할 수는 없습니다. Zookeeper는 최종 일관성만 보장할 수 있지만 강력한 일관성은 보장할 수 없습니다.

  (5) 감시자 getData 등록, 존재, getChildren

  (6) 감시자 생성, 삭제, setData 트리거

  (7) 클라이언트가 새 서버에 연결되면 세션 이벤트에 의해 watch가 트리거됩니다. 서버와의 연결이 끊어지면 시계를 수신할 수 없습니다. 클라이언트가 다시 연결되면 필요한 경우 이전에 등록된 모든 시계가 다시 등록됩니다. 일반적으로 이는 완전히 투명합니다. 감시가 손실될 수 있는 특별한 경우는 단 하나뿐입니다. 생성되지 않은 znode에 있는 기존 감시의 경우 클라이언트가 연결 해제된 동안 생성되었다가 이후에 클라이언트가 연결되기 전에 삭제된 경우 이 감시 이벤트가 손실될 수 있습니다.

  7. 클라이언트가 Watcher 구현을 등록하는 방법

  (1) 세 가지 API getData()/getChildren()/exist()를 호출하고 Watcher 객체를 전달합니다

  (2) 요청을 표시합니다. request, Watcher를 WatchRegistration으로 캡슐화

  (3) Packet 객체로 캡슐화하여 서버에 요청 보내기

  (4) 서버로부터 응답을 받은 후 Watcher를 ZKWatcherManager에 등록하여 관리

  (5) 요청이 반환되고 등록이 완료됩니다.

  8. 서버가 Watcher 구현을 처리하는 방법

  (1) 서버는 Watcher를 수신하여 저장합니다.

  클라이언트 요청을 수신하고 Watcher를 등록해야 하는지 확인하기 위해 요청을 처리합니다. 필요한 경우 데이터 노드를 변경합니다. 노드 경로와 ServerCnxn(ServerCnxn은 클라이언트와 서버 간의 연결을 나타내며 Watcher의 프로세스 인터페이스를 구현하며 현재 Watcher 객체로 간주될 수 있음)은 WatchTable 및 watch2Paths에 저장됩니다. WatcherManager.

  (2) 감시자 트리거

  setData() 트랜잭션 요청을 수신하는 서버를 예로 들어 NodeDataChanged 이벤트를 트리거합니다.

  2.1 WatchedEvent 캡슐화

  알림 상태(SyncConnected), 이벤트 유형(NodeDataChanged) 및 노드를 캡슐화합니다. 하나의 WatchedEvent 객체에 대한 경로

  2.2 Query Watcher

  노드 경로를 기반으로 WatchTable에서 Watcher를 찾습니다.

  2.3 이 데이터 노드에 Watcher를 등록한 클라이언트가 없음을 나타냅니다.

  2.4 WatchTable 및 Watch2Paths에서 해당 Watcher를 찾아 추출하고 삭제합니다. (여기서 Watcher는 서버 측에서 일회성이며 한 번 트리거된 후에는 유효하지 않게 됨을 알 수 있습니다.)

  (3) 프로세스 메서드를 호출하여 Trigger the Watcher

  프로세스는 다음과 같습니다. 주요 목적은 ServerCnxn에 해당하는 TCP 연결을 통해 Watcher 이벤트 알림을 보내는 것입니다.

  9. 클라이언트가 Watcher를 호출하는 방법

  클라이언트 SendThread 스레드가 이벤트 알림을 수신하고 EventThread 스레드가 Watcher를 호출합니다.

  클라이언트의 감시자 메커니즘도 일회성입니다. 일단 트리거되면 감시자는 무효화됩니다.

  10. ACL 권한 제어 메커니즘에 대해 잘 알고 계시나요?

  UGO(사용자/그룹/기타)

  는 현재 Linux/Unix 파일 시스템에서 사용되며 가장 널리 사용되는 권한 제어 방법이기도 합니다. 이는 대략적인 파일 시스템 권한 제어 모드입니다.

  ACL(액세스 제어 목록) 액세스 제어 목록

  에는 세 가지 측면이 포함됩니다.

  • 권한 모드(체계)

  (1) IP: IP 주소 세분화에서 권한 제어

  (2) 다이제스트: 가장 일반적으로 사용된 권한은 사용자 이름:비밀번호와 유사한 권한 식별자를 사용하여 구성됩니다. 이는 권한 제어를 위한 다양한 애플리케이션을 구별하는 데 편리합니다

  (3) 세계: 가장 개방적인 권한 제어 방법, 권한이 하나만 있는 특수 다이제스트 모드 식별 "세계: 누구든지"

  (4) 슈퍼: 슈퍼유저

  • 인증 개체

  인증 개체는 IP 주소나 기계 조명 등 권한을 부여받은 사용자 또는 지정된 개체를 의미합니다.

  • Permission

  (1) CREATE: 승인된 개체가 이 Znode 아래에 하위 노드를 생성할 수 있도록 허용하는 데이터 노드 생성 권한

  (2) DELETE: 승인된 개체가 이 데이터의 하위 노드를 삭제할 수 있도록 허용하는 하위 노드 삭제 권한 node 노드

  (3) READ: 승인된 개체가 데이터 노드에 액세스하고 해당 데이터 콘텐츠 또는 하위 노드 목록 등을 읽을 수 있도록 허용하는 데이터 노드의 읽기 권한입니다.

  (4) WRITE: 데이터 노드 업데이트 권한, 승인된 개체가 업데이트 작업을 수행하도록 허용

  (5) ADMIN: 데이터 노드 관리 권한, 승인된 개체가 데이터 노드에서 ACL 관련 설정 작업을 수행하도록 허용

  11. feature

  버전 3.2.0 이후에는 각 클라이언트가 자체적으로 네임스페이스를 설정할 수 있는 Chroot 기능이 추가되었습니다. 클라이언트에 Chroot가 설정된 경우 클라이언트가 서버에서 수행하는 모든 작업은 자체 네임스페이스로 제한됩니다.

  Chroot를 설정하면 클라이언트를 Zookeeper 서버의 하위 트리에 적용할 수 있습니다. 여러 애플리케이션이 Zookeeper를 그룹으로 공유하는 시나리오에서는 서로 다른 애플리케이션 간의 상호 격리를 달성하는 데 매우 유용합니다.

  12. 세션 관리에 익숙하십니까?

  버킷팅 전략: Zookeeper가 세션을 다른 블록과 동일한 블록에 격리할 수 있도록 동일한 블록에 배치합니다.

  분배 원칙: 각 세션의 "다음 타임아웃 시점"(ExpirationTime)

  계산 공식:

  ExpirationTime_ = currentTime + sessionTimeout

  ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *

  ExpirationInterval , ExpirationInterval은 Zookeeper 세션을 나타냅니다. 시간 초과 확인 간격, 기본 TickTime

  13. 서버의 역할은 무엇입니까

  Leader

  (1) 클러스터 트랜잭션 처리 순서를 보장하는 트랜잭션 요청의 유일한 스케줄러 및 프로세서

  (2) 각 서비스의 스케줄러 inside the Cluster

  Follower

  (1) 클라이언트의 비거래 요청 처리 및 리더 서버로 거래 요청 전달

  (2) 거래 요청 제안 투표 참여

  (3) 리더 선출 투표 참여

  Observer

  (1) 버전 3.0 클러스터의 트랜잭션 처리 기능에 영향을 주지 않고 클러스터의 비트랜잭션 처리 기능을 향상시키기 위해 나중에 서버 역할이 도입될 예정입니다.

  (2) 클라이언트의 비트랜잭션 요청을 처리하고 트랜잭션 요청을 리더 서버

  (3) 어떤 형태의 투표에도 참여하지 마세요

  14. Zookeeper 하에서 서버 작동 상태

  서버에는 LOOKING, FOLLOWING, LEADING, OBSERVING의 네 가지 상태가 있습니다.

  (1) LOOKING: 리더 상태를 찾고 있습니다. 서버가 이 상태에 있으면 현재 클러스터에 리더가 없다고 생각하므로 리더 선택 상태로 들어가야 합니다.

  (2) FOLLOWING: 팔로워 상태. 현재 서버 역할이 추종자임을 나타냅니다.

  (3) 주요: 리더 상태. 현재 서버 역할이 리더임을 나타냅니다.

  (4) 관찰: 관찰자 상태. 현재 서버 역할이 관찰자임을 나타냅니다.

  15. 데이터가 어떻게 동기화되는지 알려주실 수 있나요?

  전체 클러스터가 리더 선출을 완료한 후 학습자(팔로워와 옵저버의 총칭)가 리더 서버에 다시 등록됩니다. Learner 서버는 Leader 서버에 등록을 완료한 후 데이터 동기화 단계에 들어갑니다.

  데이터 동기화 프로세스: (모두 메시징으로 수행)

  학습자가 Learder에 등록

  데이터 동기화

  동기화 확인

  Zookeeper의 데이터 동기화는 일반적으로 네 가지 범주로 나뉩니다.

  (1) 직접 차등 동기화(DIFF 동기화)

  (2) 롤백 후 차등 동기화(TRUNC+DIFF 동기화)

  (3) 롤백 동기화만(TRUNC 동기화)

  (4) 전체 동기화(SNAP 동기화)

  진행 중 데이터 동기화 전 Leader 서버는 데이터 동기화 초기화를 완료합니다:

  peerLastZxid:

  • 학습자 서버가 등록할 때 전송된 ACKEPOCH 메시지에서 lastZxid(학습자 서버가 처리한 마지막 ZXID)를 추출합니다.

  minCommittedLog:

  • 최소 리더 서버 제안 캐시 큐의 ZXID commitLog maxCommittedLog:
  • 리더 서버의 최대 ZXID 제안 캐시 큐 commitLog 직접 차등 동기화(DIFF 동기화)
  • 시나리오: 피어LastZxid가 minCommittedLog와 maxCommittedLog 사이에 있으며 먼저 롤백하고 그런 다음 차등 동기화(TRUNC+DIFF 동기화)
  • 시나리오: 새 Leader 서버가 Learner 서버에 자신이 갖고 있지 않은 트랜잭션 기록이 포함되어 있음을 발견하면 Learner 서버가 트랜잭션 롤백(리더로 롤백)을 수행하도록 해야 합니다. 서버에 존재하며 피어LastZxid와 가장 가까운

  ZXID는 동기화(TRUNC 동기화)만 롤백합니다

  • 시나리오: 피어LastZxid가 maxCommittedLog

  전체 동기화(SNAP 동기화)

  • 시나리오 1: 피어LastZxid가 minCommittedLog보다 작음
  • 리더서버와 PeerLastZ xid는 lastProcessZxid

  16과 동일하지 않습니다. Zookeeper는 트랜잭션의 순차적 일관성을 어떻게 보장합니까?

  zookeeper는 이를 식별하기 위해 전역적으로 증가하는 트랜잭션 ID를 사용합니다. zxid는 실제로 64비트 숫자이고 상위 32비트는 epoch 세기입니다. ; 새로운 시대)은 리더 주기를 식별하는 데 사용됩니다. 새 리더가 생성되면 에포크가 자동으로 증가하고 하위 32비트가 카운트를 증가시키는 데 사용됩니다. 새로운 제안이 생성되면 먼저 데이터베이스의 2단계 프로세스를 기반으로 다른 서버에 트랜잭션 실행 요청을 발행하고 절반 이상의 머신이 이를 실행하고 성공하면 실행이 시작됩니다.

  17. 분산 클러스터에 마스터 노드가 있는 이유는 무엇인가요?

  분산 환경에서 일부 비즈니스 로직은 클러스터 내의 특정 머신에서만 실행하면 되고, 다른 머신은 결과를 공유할 수 있어 반복 계산을 크게 줄이고 성능을 향상시킬 수 있으므로 리더 선출이 필요합니다. .

  18. zk 노드 가동 중지 시간을 처리하는 방법은 무엇입니까?

  Zookeeper 자체도 클러스터이므로 서버를 3대 이상 구성하는 것을 권장합니다. Zookeeper 자체도 한 노드가 다운되더라도 다른 노드가 계속해서 서비스를 제공하도록 보장해야 합니다.

  팔로워가 다운되더라도 액세스를 제공하는 서버는 2개입니다. Zookeeper의 데이터에는 여러 복사본이 있으므로 데이터는 손실되지 않습니다.

  리더가 다운되면 Zookeeper가 새로운 리더를 선출합니다.

  ZK 클러스터의 메커니즘은 노드의 절반 이상이 정상이면 클러스터가 정상적으로 서비스를 제공할 수 있다는 것입니다. ZK 노드가 너무 많고 노드의 절반 또는 절반 미만만 작동할 수 있는 경우에만 클러스터가 실패합니다.

  그래서

  3개의 노드로 구성된 클러스터는 1개의 노드에 실패할 수 있습니다(리더는 2표>1.5를 얻을 수 있음)

  2개의 노드로 구성된 클러스터는 어떤 노드에도 실패할 수 없습니다(리더는 1표<=1을 얻을 수 있음)

  19. Zookeeper 로드 밸런싱 및 nginx 로드 밸런싱

  zk의 로드 밸런싱은 조정 가능하며, nginx는 가중치만 조정할 수 있으며, 제어해야 하는 다른 것들은 자체 플러그인을 작성해야 하지만 nginx의 처리량은 더 높습니다. zk는 업무에 따라 어떤 방법을 사용할지 선택한다고 해야 할까요.

  20. Zookeeper의 배포 모드는 무엇입니까?

  Zookeeper에는 세 가지 배포 모드가 있습니다.

  • 단일 머신 배포: 하나의 클러스터에서 실행
  • 클러스터 배포: 여러 클러스터에서 실행
  • 유사 클러스터 배포: 여러 클러스터 시작 클러스터 1개 Zookeeper 인스턴스가 실행 중입니다.

  21. 클러스터에는 최소한 몇 대의 머신이 필요합니까? 클러스터에 서버가 3개 있는데, 노드 중 하나가 다운되었습니다. 이때도 Zookeeper를 사용할 수 있나요?

  클러스터 규칙은 2N+1 단위, N>0, 즉 3개 단위입니다. 서버의 절반 이상이 다운되지 않는 한 홀수 서버를 계속 사용할 수 있습니다.

  22. 클러스터는 머신의 동적 추가를 지원합니까?

  사실 수평적 확장은 이런 면에서는 별로 좋지 않습니다. 두 가지 방법:

  • 모두 다시 시작: 모든 Zookeeper 서비스를 닫고 구성을 수정한 후 시작합니다. 이전 클라이언트 세션에는 영향을 주지 않습니다.

  • 하나씩 다시 시작: 머신의 절반 이상이 살아 있고 사용 가능하다는 원칙에 따라 머신 하나를 다시 시작해도 전체 클러스터의 외부 서비스에 영향을 미치지 않습니다. 이것이 더 일반적으로 사용되는 방법입니다.

  버전 3.5에서 동적 확장을 지원하기 시작합니다.

  23. Zookeeper의 노드 감시 알림은 영구적인가요?

  아니요. 공식 설명: Watch 이벤트는 Watch가 설정된 데이터가 변경되면 서버가 Watch가 설정된 클라이언트에 변경 사항을 전송하여 이를 알리는 일회성 트리거입니다.

  영구적이지 않은 이유는 무엇인가요? 예를 들어 서버가 자주 변경되고 모니터링 클라이언트가 많은 경우 모든 클라이언트에 변경 사항을 알려야 하므로 네트워크와 서버에 많은 부담이 가해집니다.

  일반적으로 클라이언트는 getData("/node A", true)를 실행합니다. 노드 A가 변경되거나 삭제되면 클라이언트는 감시 이벤트를 받지만 노드 A가 다시 변경되고 클라이언트는 감시 이벤트가 아닌 경우 설정하면 더 이상 클라이언트로 전송되지 않습니다.

  실제 응용 프로그램에서 많은 경우 클라이언트는 서버의 모든 변경 사항을 알 필요가 없으며 최신 데이터만 필요합니다.

  24. Zookeeper의 Java 클라이언트는 무엇인가요?

  java 클라이언트: zk의 자체 zkclient 및 Apache의 오픈 소스 큐레이터.

  25.통통이란 무엇이며 사육사와 어떻게 비교하나요?

  chubby는 Google에서 제작되었으며 paxos 알고리즘을 완전히 구현하며 오픈 소스가 아닙니다. Zookeeper는 paxos 알고리즘의 변형인 zab 프로토콜을 사용하는 Chubby의 오픈 소스 구현입니다.

  26. 사육사에서 자주 사용하는 명령어에 대해 이야기해 보겠습니다.

  일반적인 명령: ls get set create delete 등.

  27. ZAB와 Paxos 알고리즘의 연관성과 차이점은 무엇인가요?

  동일점:

  (1) 둘 다 여러 Follower 프로세스의 실행을 조정하는 리더 프로세스와 유사한 역할을 합니다.

  (2) 리더 프로세스는 프로세스의 절반 이상을 기다립니다. 팔로어가 결정을 내립니다. 올바른 피드백 후에만 제안이 제출됩니다

  (3) ZAB 프로토콜에서 각 제안에는 현재 리더 주기를 나타내는 에포크 값이 포함됩니다. Paxos의 이름은 Ballot

  차이점:

  ZAB입니다. 고가용성 분산 데이터 마스터 및 백업 시스템(Zookeeper)을 구축하는 데 사용되며, Paxos는 분산 일관성 상태 머신 시스템을 구축하는 데 사용됩니다.

  28. Zookeeper의 일반적인 애플리케이션 시나리오

  Zookeeper는 개발자가 분산 데이터를 게시하고 구독하는 데 사용할 수 있는 일반적인 게시/구독 모델 분산 데이터 관리 및 조정 프레임워크입니다.

  Zookeeper의 풍부한 데이터 노드를 교차 사용하고 Watcher 이벤트 알림 메커니즘과 협력함으로써 다음과 같이 분산 애플리케이션과 관련된 일련의 핵심 기능을 구축하는 것이 매우 편리합니다.

  (1) 데이터 게시/ 구독

  (2) 로드 밸런싱

  (3) 이름 지정 서비스

  (4) 분산 조정/알림

  (5) 클러스터 관리

  (6) 마스터 선거

  (7) 분산 잠금

  (8) 분산 대기열

  29. Zookeeper에는 어떤 기능이 있나요?

  클러스터 관리: 노드 생존 상태, 실행 중인 요청 등을 모니터링합니다.

  마스터 노드 선출: 마스터 노드가 중단된 후 백업 노드에서 새로운 리더 선출 라운드를 시작할 수 있습니다. 마스터 노드 선택에 관한 것입니다. Zookeeper를 사용하면 이 프로세스를 완료하는 데 도움이 될 수 있습니다.

  분산 잠금: Zookeeper는 독점 잠금과 공유 잠금이라는 두 가지 유형의 잠금을 제공합니다. 배타적 잠금은 한 번에 하나의 스레드만 리소스를 사용할 수 있음을 의미하고, 공유 잠금은 읽기 잠금이 공유되고 읽기 및 쓰기가 상호 배타적임을 의미합니다. 즉, 여러 스레드가 동시에 동일한 리소스를 읽을 수 있다는 의미입니다. 쓰기 잠금이 사용되면 하나의 스레드만 이를 사용할 수 있습니다. Zookeeper는 분산 잠금을 제어할 수 있습니다.

  이름 지정 서비스: 분산 시스템에서 이름 지정 서비스를 사용하면 클라이언트 애플리케이션은 지정된 이름을 기반으로 리소스나 서비스의 주소, 공급자 및 기타 정보를 얻을 수 있습니다.

  30. Zookeeper의 알림 메커니즘에 대해 알려주세요.

  클라이언트는 특정 znode에 대한 감시자 이벤트를 생성합니다. znode가 변경되면 이러한 클라이언트는 zk 알림을 받게 되며 클라이언트는 znode 변경 사항에 따라 비즈니스를 변경할 수 있습니다.

  31. 주키퍼와 더보는 어떤 관계인가요?

  Zookeeper의 역할

  zookeeper는 어떤 서비스가 어떤 시스템에서 제공되는지를 간단히 말하면 IP 간의 대응입니다. 주소와 서비스 이름. 물론 이 대응은 하드 코딩을 통해 발신자의 비즈니스 코드에도 구현될 수 있습니다. 그러나 서비스를 제공하는 기계가 전화를 끊으면 발신자는 코드가 변경되지 않으면 계속해서 요청하게 됩니다. 서비스를 제공하는 죽은 기계. Zookeeper는 하트비트 메커니즘을 통해 정지된 시스템을 감지하고 정지된 시스템의 IP와 서비스 간의 해당 관계를 목록에서 삭제할 수 있습니다. 높은 동시성을 지원한다는 것은 쉽게 말하면 수평적 확장, 코드 변경 없이 머신을 추가해 컴퓨팅 파워를 높이는 것을 의미한다. ZooKeeper에 서비스를 등록하기 위해 새로운 시스템을 추가함으로써 더 많은 서비스 제공자가 있을수록 더 많은 고객에게 서비스를 제공할 수 있습니다.

  dubbo

  는 비즈니스 계층과 데이터 웨어하우스 사이에 예약이 필요한 많은 서비스 액세스와 서비스 제공자를 관리하는 도구입니다.

  여기의 더보는 단지 프레임일 뿐이라는 점을 참고하세요. 선반에 무엇을 놓을지는 전적으로 여러분의 몫입니다. 자동차 뼈대처럼 휠 엔진도 맞춰야 합니다. 이 프레임워크에서 스케줄링을 완료하려면 모든 서비스의 메타데이터를 저장하는 분산 등록 센터가 있어야 합니다. zk나 다른 서비스를 사용할 수 있지만 모두가 zk를 사용합니다.

  주키퍼와 dubbo의 관계:

  Dubbo는 등록 센터를 추상화하여 다양한 저장 매체를 외부적으로 연결하여 ZooKeeper, Memcached, Redis 등을 포함하여 등록 센터에 서비스를 제공할 수 있습니다.

  ZooKeeper를 저장 매체로 소개하면 ZooKeeper의 기능도 소개됩니다. 첫 번째는 로드 밸런싱입니다. 단일 등록 센터의 전송 용량은 제한되어 있습니다. 트래픽이 특정 수준에 도달하면 트래픽을 전환하기 위한 로드 밸런싱이 존재합니다. ZooKeeper 그룹은 쉽게 로드 밸런싱을 달성할 수 있습니다. 해당 웹 애플리케이션. 리소스 동기화, 로드 밸런싱만으로는 충분하지 않으며 노드 간 데이터와 리소스를 동기화해야 하며 ZooKeeper 클러스터에는 트리 구조를 사용하여 글로벌 서비스 주소 목록을 유지하는 기능이 있습니다. 서비스 제공자 시작할 때 ZooKeeper에 지정된 노드의 /dubbo/${serviceName}/providers 디렉토리에 자신의 URL 주소를 작성하면 서비스 릴리스가 완료됩니다. 다른 기능으로는 마스트 선거, 분산 잠금 등이 있습니다.

  

  
  

위 내용은 [추천컬렉션] 영혼의 고문! 사육사의 31발 대포의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!