CAP theorem – Consistency vs Availability

-
Theo nguyên tắc CAP(CAP theorem) thì 1 hệ thống thiết kế phân tán sẽ không thể thỏa mãn cả 3 điều kiện:
Consistency(nhất quán) : trong 1 hệ thống phân tán,mọi request tới hệ thống phải có phản hồi kết quả là lần ghi cuối cùng hoặc thông báo lỗi.
Availability(có hiệu lực) : trong 1 hệ thống phân tán,  có nhiều server(node), request của bạn tới tất cả các server đều trả kết quả (yêu cầu gửi đi phải có phúc đáp).
Partition tolerance(phân mảnh): hệ thống vẫn hoạt động được(thực hiện chức năng hoặc đáp trả query) ngay cả khi mạng bị lỗi (1 bộ phận bị lỗi hay cô lập) hoặc có độ trễ khi gửi message (hoặc mất mesage) giữa các node.
PA – Trường hợp hệ thống đảm bảo được tính sẳn sàng(A) và cho phép phân mảnh, mất kết nối mạng (P): Ứng dụng web bán hàng, trong nghiệp vụ xử lí đơn hàng, phân hệ thanh toán và phân hệ đơn hàng cùng nhận được yêu cầu xử lí đơn hàng. Mặc dù phân hệ đơn hàng mất kế nối với db nhưng phân hệ thanh toán vẫn được xử lí bình thường. Việc này đã làm giảm nhất quán (C) giữa db đơn hàng và db thanh toán, tuy nhiên ứng dụng vẫn sẳn sàng (A) phản hồi trạng thái xử lí đơn hàng thành công.
PA là mô hình thường được áp dụng với các hệ thống phân tán.
PC – Trường hợp hệ thống đảm bảo được tính nhất quán(C), cho phép phân mảnh, mất kết nối mạng(P): Hệ thống web đọc tin mất kết nối với db, ứng dụng vẫn cho phép đọc tin tức (P) với dữ liệu lưu trong cache, mặc dù không đọc được bài mới, không xuất bản được bài viết mới do mất kết nối với db. Node ghi log visit cũng không sẳn sàng(A), không thực hiện lưu ký được.
PC là trường hợp sảy ra khi các node trong hệ thống phân tán xử lí dữ liệu độc lập. Các lớp ứng dụng này thường sử dụng thêm các hệ thống phụ trợ như memcache, redis, hbase,..
AC – Hệ thống vẫn đảm bảo sẳn sàng và giữ cho nhất quán nhưng không cho phép bị phân mảnh. Ứng dụng mất kế nối với db. Bản chất hiện tượng này, ứng dụng vẫn sẳn sàng(hiển thị lỗi, hiển thị thông báo từ chối dịch vụ hoặc không hiển thị nội dụng) và vẫn đảm bảo tính nhất quán của dữ liệu.
Trường hợp AC dễ thấy và là đặc điểm thông thường của các ứng dụng nguyên khối 3 lớp giản dị; thuần túy sử dụng cơ sở dữ liệu quan hệ.
Rất khó cân bằng giữa 2 điều kiện Consistency và Availability. Tùy theo hệ thống mà việc thiết kế sẽ phải hi sinh độ cân bằng của 2 đặc tính này. Khi sự cân bằng bị mất nghĩa là đã xuất hiện phân mảnh. Trường hợp hệ thống xuất hiện phân mảnh gần như không có. Không hệ thống phân tán nào muốn xảy ra partiting vì khi nó xảy ra, hệ thống đó không còn được gọi là phân tán. Trong trường hợp đó giải pháp thường được áp dụng là là giảm tính nhất quán để đánh đổi tính sẳn sàng (A) và cho phép phân mảnh (P). Với AP người ta thay thế nhất quán (Consistency) bằng nhất quán cuối (Eventually Consistency)
Nhất quán cuối
Theo Werner Vogels – CIO của Amazon và là cựu giáo sư khoa Khoa học Máy tính của trường Đại học Cornell (Mỹ). Werner đề xuất một hướng đi mới trong việc xây dựng các hệ thống dữ liệu lớn, tách khỏi cách tiếp cận của các hệ QT CSDL quan hệ truyền thống. Cách tiếp cận mới này giúp tăng khả năng sẵn sàng (A – availability) và mở rộng (scalability) lên rất nhiều, vốn là các ưu tiên hàng đầu của các hệ thống lớn trên Internet. Werner đã tạo “cơ sở lý luận” vững chắc cho phong trào NoSQL (Not Only SQL) đang phát triển rất mạnh. Đại biểu của phong trào này là các hệ thống mới phát triển gần đây như Dynamo (phát triển/áp dụng tại Amazon), Cassandra (Facebook, Digg), CouchDB, MongoDB. Werner khái niệm eventual consistency – trong đó hệ thống cam kết rằng, một cập nhật xảy ra tại một điểm sẽ được lan truyền và sau một khoảng thời gian (không phải ngay tức khắc) sẽ lan truyền đến mọi điểm trong hệ thống và cuối cùng (eventually) hệ thống sẽ trở lại trạng thái nhất quán.  Thuật ngữ này tạm dịch là “nhất quán cuối cùng”. Hầu như ae VN đều sử dụng thuật ngữ này nên chúng ta sẽ thống nhất gọi là “nhất quán cuối” hoặc “nhất quá muộn“.

Xem thêm:
availability keywords: cluster, .. citrix balancing, caching, ngix balancing, ..
consistency keywords:raft , Apache ZooKeeper™, ..

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

Open Source CMS Ecommerce in .Net Core

-
SimplCommerce A simple, cross platform, modularized ecommerce system built on .NET Core https://github.com/simplcommerce/SimplCommerce DotNetify DotNetify is a free, open source project that lets you create real-time, reactive, cross-platform apps with React, React Native, or Knockout front-end on C# .NET back-end via WebSocket. https://github.com/dsuryd/dotnetify-react-demo-vs2017 https://github.com/dsuryd/dotNetify Weapsy Weapsy is an ASP.NET Core CMS based on DDD and CQRS. https://github.com/weapsy/Weapsy C# ASP.NET Core JavaScript, jQuery Entity Framework Core MSSQL, MySQL, SQLite, PostgreSQL DDD CQRS Platformus Platformus is free, open source and cross-platform CMS based on ASP.NET Core and  ExtCore framework . It is built using the best and the most modern tools and languages (Visual Studio 2017, C# etc). Join our team! https://github.com/platformus/Platformus/ Cofoundry (CMS) Cofoundry is an extensible and flexible .NET Core CMS & a...
Đọc thêm

What is an Application Specialist?

-
An Applications Specialist is needed in all sectors of industry that use software systems.   They may alter existing software, install new software and troubleshoot any problems related to performance of computer systems.   Application Specialists are expected to be expert in several computer programs and data interfaces. Most computer support specialists follow full-time work schedules;   however, many do not work a typical 9-to-5 day.   As it is a support position it is important for businesses that Application Specialists be available 24 hours a day if necessary.   Generally their schedules are often staggered 8-hour shifts to cover 24 hours of a day.   Therefore many Application Specialists can find themselves working at night or during the weekend.   Applications specialists work mainly in an office setting and many are able to work from home.   Some jobs may require travel.   This is a promising career as employment for Application S...
Đọc thêm

Sharding, Snowflake Instagram trong bài toán đối soát dữ liệu

-
Có 3 vấn đề về chất lượng dữ liệu của hệ thống: - Dữ liệu không đồng nhất giữa các phiên bản được lưu trữ tại các kho khác nhau - Dữ liệu bị trùng lặp - Dữ liệu bị sai bản chất ngữ nghĩa. Việc sai này có thể do định nghĩa sai, hoặc do nghiệp vụ thay đổi. Xem thêm tại  Quản lí chất lượng dữ liệu Việc đối soát dữ liệu trong hệ thống có sự trao đổi thông tin(trao đổi nội bộ giữa các phân hệ hoặc giữa ứng dụng với ứng dụng khác) là nghiệp vụ thường xuyên nhằm duy trì chất lượng dữ liệu. Trong bài này, tôi chỉ tập trung vào việc đối soát dữ liệu giữa các phiên bản được lưu trữ tại các kho khác nhau. Kho trong trường hợp này, tôi xem xét là 1 cơ sở dữ liệu quan hệ(oracle, mysql, sql server). Nguyên lý quản lý đối soát dữ liệu: 1.RÀNG BUỘC - Nguyên tắc: chỉ đối soát sự tồn tại với phiên bản dữ liệu (data version), không đối soát chi tiết thuộc tính của thực thể(item) - Lý do: Tất cả các nghiệp vụ trao đổi thông tin đã được xử lý theo giao dịch 2. VẤN ĐỀ MỤC TIÊU - Đối soát...
Đọc thêm