Thiết kế hệ thống Hacks:

1. ) Viết hệ thống nặng — Reference-1 , Reference-2
2. ) Đọc Hệ thống nặng — Reference-1 , Reference-2
3. ) Định lý CAP -

5. ) AP (Khả dụng với dung sai phân vùng) — Cassandra, Dynamo, CouchDB, Riak, Tìm kiếm đàn hồi, MongoDB (Đã sao chép).

6.) CA (Tính nhất quán với tính khả dụng) - MySQL, Postgres.

Ghi chú ngắn tham khảo:

MongoDB - Theo mặc định, MongoDB rất nhất quán — nếu bạn ghi rồi đọc, giả sử quá trình ghi thành công, bạn sẽ luôn có thể đọc kết quả của thao tác ghi mà bạn vừa đọc. Điều này là do MongoDB là một hệ thống một chủ và tất cả các lần đọc đều chuyển sang hệ thống chính theo mặc định. Nếu bạn tùy chọn cho phép đọc từ các phần phụ thì MongoDB cuối cùng sẽ trở nên nhất quán khi có thể đọc các kết quả lỗi thời. MongoDB cũng có tính khả dụng cao thông qua chuyển đổi dự phòng tự động trong các bộ bản sao:http://www.mongodb.org/display/DOCS/Replica+Sets

Đảm bảo tính nhất quán của Redis Cluster -

Redis Cluster không đảm bảo tính nhất quán cao. Trên thực tế, điều này có nghĩa là trong một số điều kiện nhất định, có thể Redis Cluster sẽ mất khả năng ghi mà hệ thống đã xác nhận cho máy khách.

Lý do đầu tiên khiến Redis Cluster có thể mất khả năng ghi là vì nó sử dụng bản sao không đồng bộ. Điều này có nghĩa là trong quá trình ghi, những điều sau đây sẽ xảy ra:

Khách hàng của bạn viết thư cho chủ B.

Master B trả lời OK cho khách hàng của bạn.

Master B truyền ghi tới các bản sao B1, B2 và B3 của nó.

Như bạn có thể thấy, B không đợi xác nhận từ B1, B2, B3 trước khi trả lời ứng dụng khách, vì đây sẽ là một hình phạt về độ trễ nghiêm trọng đối với Redis, vì vậy nếu ứng dụng khách của bạn viết nội dung nào đó, B sẽ xác nhận việc ghi, nhưng gặp sự cố trước đó có thể gửi ghi đến các bản sao của nó, một trong các bản sao (không nhận được ghi) có thể được thăng cấp thành chủ, mất ghi vĩnh viễn.

Trong Redis, Tính khả dụng cao không chỉ là Dung sai phân vùng. Redis có kiến ​​trúc Master Slave và nếu Master bị lỗi thì Redis Sentinels thăng cấp Slave làm Master mới, giúp toàn bộ giải pháp có tính khả dụng cao. Và một bản gốc có thể bị lỗi (hoặc không khả dụng) vì một số lý do (ví dụ: hết bộ nhớ), không nhất thiết là do Phân vùng mạng.

Sau đó, đến trường hợp Phân vùng mạng (P) và nếu (P) xảy ra thì Redis sẽ không khả dụng trong phân vùng thiểu số. Đó là lý do tại sao từ quan điểm của CAP, Redis là CP vì nó không khả dụng trong các phân vùng thiểu số. Xin lưu ý rằng nó sẽ vẫn có sẵn trong phân vùng đa số.

Bạn có thể đọc thêm về Redis High Availability tại đây . Tham khảo đoạn có tiêu đề “Tính nhất quán trong phân vùng” để biết chi tiết về Phân vùng.

Redis còn được gọi là nhất quán cuối cùng vì khi (P) xảy ra, phân vùng thiểu số vẫn khả dụng trong vài giây và bất kỳ thao tác ghi nào được thực hiện trong khoảng thời gian đó trên phân vùng thiểu số cuối cùng sẽ bị loại bỏ.

Cassandra — bấm vào đây