https://zookeeper.apache.org/doc/current/zookeeperOver.html
Theo mặc định, Zookeeper sao chép tất cả dữ liệu của bạn tới mọi nút và cho phép khách hàng xem dữ liệu để biết các thay đổi. Các thay đổi được gửi rất nhanh chóng (trong một khoảng thời gian nhất định) cho khách hàng. Bạn cũng có thể tạo "nút tạm thời", sẽ bị xóa trong một thời gian nhất định nếu khách hàng ngắt kết nối. ZooKeeper được tối ưu hóa cao cho lần đọc , trong khi quá trình ghi diễn ra rất chậm (vì chúng thường được gửi đến mọi khách hàng ngay sau khi quá trình ghi diễn ra). Cuối cùng, kích thước tối đa của "tệp" (znode) trong Zookeeper là 1MB, nhưng thông thường chúng sẽ là các chuỗi đơn.
Tổng hợp lại, điều này có nghĩa là người quản lý sở thú không phải để lưu trữ nhiều dữ liệu và chắc chắn không phải là bộ nhớ cache. Thay vào đó, nó để quản lý nhịp tim / biết máy chủ nào đang trực tuyến, lưu trữ / cập nhật cấu hình và có thể truyền thông báo (mặc dù nếu bạn có số lượng thư lớn hoặc yêu cầu thông lượng cao, một cái gì đó như RabbitMQ sẽ tốt hơn nhiều cho nhiệm vụ này).
Về cơ bản, ZooKeeper (và Curator, được xây dựng trên nó) giúp xử lý cơ chế phân nhóm - nhịp tim, phân phối cập nhật / cấu hình, khóa phân tán, v.v.
Nó không thực sự so sánh với Redis, nhưng đối với các câu hỏi cụ thể ...
-
Nó không hỗ trợ bất kỳ tính toán nào và đối với hầu hết các tập dữ liệu, sẽ không thể lưu trữ dữ liệu với bất kỳ hiệu suất nào.
-
Nó được sao chép tới tất cả các nút trong cụm (không có gì giống như Redis clustering nơi dữ liệu có thể được phân phối). Tất cả các tin nhắn được xử lý nguyên tử đầy đủ và được sắp xếp theo trình tự, vì vậy không có giao dịch thực sự. Nó có thể được SỬ DỤNG để triển khai các khóa toàn cụm cho các dịch vụ của bạn (thực tế là rất tốt) và tehre là rất nhiều khóa nguyên thủy trên chính các znodes để kiểm soát các nút nào truy cập chúng.
-
Chắc chắn, nhưng ZooKeeper lấp đầy một vị trí thích hợp. Đó là một công cụ để làm cho một ứng dụng phân tán hoạt động tốt với nhiều phiên bản, không phải để lưu trữ / chia sẻ một lượng lớn dữ liệu. So với việc sử dụng IMDG cho mục đích này, Zookeeper sẽ nhanh hơn, quản lý nhịp tim và đồng bộ hóa theo cách có thể dự đoán được (với rất nhiều API để thực hiện phần này dễ dàng) và có mô hình "đẩy" thay vì "kéo" để các nút được thông báo rất nhanh về các thay đổi.
Trích dẫn từ câu hỏi được liên kết ...
Một ví dụ chính tắc về việc sử dụng Zookeeper là tính toán bộ nhớ phân tán
... là IMO, hơi gây hiểu nhầm. Bạn sẽ sử dụng nó để sắp xếp việc tính toán chứ không phải cung cấp dữ liệu. Ví dụ:giả sử bạn phải xử lý hàng 1-100 của bảng. Bạn có thể đặt 10 nút ZK lên, với các tên như "1-10", "11-20", "21-30", v.v. Các ứng dụng khách sẽ được ZK tự động thông báo về thay đổi này và nút đầu tiên sẽ lấy " 1-10 "và đặt một nút tạm thời clients/192.168.77.66/processing/rows_1_10
Ứng dụng tiếp theo sẽ thấy điều này và chuyển sang nhóm tiếp theo để xử lý. Dữ liệu thực tế để tính toán sẽ được lưu trữ ở nơi khác (tức là Redis, cơ sở dữ liệu SQL, v.v.). Nếu nút không thành công trong quá trình tính toán, một nút khác có thể thấy điều này (sau 30-60 giây) và bắt đầu lại công việc.
Tuy nhiên, tôi muốn nói rằng ví dụ điển hình của ZooKeeper là bầu cử lãnh đạo. Giả sử bạn có 3 nút - một là nút chính và 2 nút còn lại là nô lệ. Nếu nút chủ bị hỏng, một nút phụ phải trở thành nút dẫn đầu mới. Loại thứ này là hoàn hảo cho ZK.
