Sự khác biệt/điểm tương đồng của Hazelcast (Java) và ETCD (golang)?

Question

Bây giờ chúng tôi xây dựng một hệ thống phân tích thời gian thực và nó cần được phân phối cao. Chúng tôi dự định sử dụng các khóa và bộ đếm phân phối để đảm bảo tính nhất quán của dữ liệu và chúng tôi cần một loại bản đồ phân phối để biết khách hàng nào được kết nối với máy chủ nào. Tôi không có kinh nghiệm trước trong hệ thống phân phối trước đây, nhưng tôi nghĩ rằng chúng tôi có hai lựa chọn:

1. Java + Hazelcast

2. Golang + ETCD

Nhưng là những gì những ưu/khuyết điểm của nhau trong bối cảnh chủ đề?

Answer 1

Hazelcast và vv là hai hệ thống rất khác nhau. Lý do là CAP theorem.

Định lý CAP nêu rõ rằng không có hệ thống phân tán nào có thể có tính nhất quán, tính khả dụng và khả năng phân vùng. Các hệ thống phân tán thường rơi gần hơn với CA hoặc CP. Hazelcast là một hệ thống AP, và vvd (là một triển khai Raft) là CP. Vì vậy, sự lựa chọn của bạn là giữa sự nhất quán và tính khả dụng/hiệu suất.

Nói chung, Hazelcast sẽ hoạt động hiệu quả hơn nhiều và có khả năng xử lý nhiều lỗi hơn Raft và v.v, nhưng với chi phí các vấn đề mất dữ liệu hoặc tính nhất quán tiềm ẩn. Cách Hazelcast hoạt động là nó phân vùng dữ liệu và lưu trữ các mẩu dữ liệu trên các nút khác nhau. Vì vậy, trong một cụm nút 5, khóa "foo" có thể được lưu trữ trên các nút 1 và 2 và thanh có thể được lưu trữ trên các nút 3 và 4. Bạn có thể kiểm soát số lượng nút mà Hazelcast sao chép dữ liệu qua Hazelcast và bản đồ cấu hình. Tuy nhiên, trong một mạng hoặc lỗi khác, có một số rủi ro mà bạn sẽ thấy dữ liệu cũ hoặc thậm chí mất dữ liệu trong Hazelcast.

Cách khác, Raft và v.v là hệ thống nhất quán duy nhất có khả năng lưu trữ dữ liệu trên tất cả các nút. Điều này có nghĩa là nó không lý tưởng cho việc lưu trữ một lượng lớn trạng thái. Nhưng ngay cả khi bị lỗi mạng, v.v. có thể đảm bảo rằng dữ liệu của bạn sẽ vẫn nhất quán. Nói cách khác, bạn sẽ không bao giờ thấy dữ liệu cũ/cũ. Nhưng điều này đi kèm với chi phí. Các hệ thống CP yêu cầu đa số cụm phải hoạt động bình thường.

Sự cố nhất quán có thể có hoặc có thể không liên quan đến lưu trữ khóa-giá trị cơ bản, nhưng nó có thể cực kỳ liên quan đến khóa. Nếu bạn mong đợi các khóa của mình nhất quán trên toàn bộ cụm - nghĩa là chỉ một nút có thể giữ khóa ngay cả trong mạng hoặc lỗi khác - hãy không sử dụng Hazelcast. Bởi vì Hazelcast hy sinh tính nhất quán ủng hộ tính khả dụng (một lần nữa, xem định lý CAP), hoàn toàn có thể là sự thất bại mạng có thể dẫn tới hai nút tin rằng một khóa là tự do để có được.

Ngoài ra, Raft đảm bảo rằng trong khi mạng bị lỗi, chỉ một nút sẽ vẫn là đầu của cụm vd, và do đó tất cả các quyết định được thực hiện thông qua một nút đó. Điều này có nghĩa rằng etcd có thể đảm bảo rằng nó có một cái nhìn nhất quán về trạng thái cụm tại mọi thời điểm và có thể đảm bảo rằng một cái gì đó giống như một khóa chỉ có thể thu được bằng một quá trình duy nhất.

Thực sự, bạn cần phải xem xét những gì bạn đang tìm kiếm trong cơ sở dữ liệu của bạn và tìm kiếm nó. Các trường hợp sử dụng cho các cửa hàng dữ liệu CP và AP là rất khác nhau. Nếu bạn muốn nhất quán để lưu trữ một lượng nhỏ trạng thái, khóa nhất quán, cuộc bầu cử lãnh đạo và các công cụ điều phối khác, hãy sử dụng hệ thống CP như ZooKeeper hoặc Consul. Nếu bạn muốn có tính sẵn sàng cao và hiệu suất với chi phí tiềm năng nhất quán, hãy sử dụng Hazelcast hoặc Cassandra hoặc Riak.

Nguồn: Tôi là tác giả của a Raft implementation