Tìm hiểu vì sao các cơ sở dữ liệu phân tán thường nới lỏng tính nhất quán để giữ khả dụng khi có lỗi, cách hoạt động của định lý CAP và cơ chế quorum, và khi nào nên chọn mỗi phương án.
Khi một cơ sở dữ liệu được chia trên nhiều máy (bản sao), bạn có được tốc độ và độ bền—nhưng cũng đồng thời tạo ra các khoảng thời gian mà những máy đó không hoàn toàn đồng ý hoặc không thể giao tiếp tin cậy với nhau.
Tính nhất quán nghĩa là: sau một lần ghi thành công, mọi người đều đọc thấy cùng một giá trị. Nếu bạn cập nhật email hồ sơ, lần đọc tiếp theo—dù là bản sao nào trả lời—sẽ trả về email mới.
Trong thực tế, hệ thống ưu tiên tính nhất quán có thể trì hoãn hoặc từ chối một vài yêu cầu trong lúc xảy ra lỗi để tránh trả về câu trả lời mâu thuẫn.
Khả dụng nghĩa là: hệ thống trả lời mọi yêu cầu, ngay cả khi một vài máy chủ bị sập hoặc mất kết nối. Bạn có thể không nhận được dữ liệu mới nhất, nhưng sẽ có phản hồi.
Trong thực tế, hệ thống ưu tiên khả dụng có thể chấp nhận ghi và phục vụ đọc ngay cả khi các bản sao không đồng ý, rồi hòa giải sự khác biệt sau đó.
Một đánh đổi nghĩa là bạn không thể tối đa cả hai mục tiêu cùng một lúc trong mọi kịch bản lỗi. Nếu các bản sao không thể phối hợp, cơ sở dữ liệu phải:
Cân bằng đúng phụ thuộc vào lỗi bạn có thể chịu được: một gián đoạn ngắn, hay một khoảng thời gian dữ liệu sai/cũ. Phần lớn hệ thống thực tế chọn một điểm giữa—và làm cho đánh đổi đó rõ ràng.
Một cơ sở dữ liệu được gọi là “phân tán” khi nó lưu và phục vụ dữ liệu từ nhiều máy (nút) phối hợp qua mạng. Với ứng dụng, nó có thể vẫn trông như một cơ sở dữ liệu duy nhất—nhưng phía sau, các yêu cầu có thể được xử lý bởi các nút khác nhau ở những nơi khác nhau.
Hầu hết cơ sở dữ liệu phân tán sao chép dữ liệu: cùng một bản ghi được lưu trên nhiều nút. Các đội làm vậy để:
Sao chép rất mạnh, nhưng ngay lập tức đặt ra câu hỏi: nếu hai nút cùng có bản sao dữ liệu, làm sao đảm bảo chúng luôn đồng ý?
Trên một máy đơn, “sập” thường rõ ràng: máy chạy hoặc không. Trong hệ thống phân tán, lỗi thường mang tính một phần. Một nút có thể vẫn chạy nhưng chậm. Một liên kết mạng có thể rớt gói. Một toàn bộ rack có thể mất kết nối trong khi phần còn lại của cụm vẫn hoạt động.
Điều này quan trọng vì các nút không thể biết ngay lập tức là nút khác thật sự sập, tạm thời không truy cập được, hay chỉ đang trễ. Trong khi chờ biết, chúng vẫn phải quyết định xử lý các yêu cầu đọc và ghi đến như thế nào.
Với một máy chủ, có một nguồn chân lý: mọi lần đọc đều thấy ghi thành công gần nhất.
Với nhiều nút, “gần nhất” phụ thuộc vào sự phối hợp. Nếu một ghi thành công trên nút A nhưng nút B không thể tiếp cận, cơ sở dữ liệu nên:
Mâu thuẫn đó—do mạng không hoàn hảo tạo ra—là lý do phân phối thay đổi quy tắc.
Phân vùng mạng là một đứt quãng trong giao tiếp giữa các nút lẽ ra phải hoạt động như một cơ sở dữ liệu duy nhất. Các nút vẫn có thể chạy và khỏe, nhưng không thể trao đổi thông điệp một cách đáng tin cậy—do switch lỗi, liên kết quá tải, thay đổi định tuyến sai, cấu hình firewall sai, hoặc thậm chí một “hàng xóm ồn” trong mạng đám mây.
Khi hệ thống được trải ra trên nhiều máy (thường trên nhiều rack, vùng, hay region), bạn không còn kiểm soát mọi điểm nhảy giữa chúng. Mạng rớt gói, gây trễ, và đôi khi tách thành các “hòn đảo.” Ở quy mô nhỏ, những sự kiện này hiếm; ở quy mô lớn, chúng là thường xuyên. Ngay cả gián đoạn ngắn cũng đủ gây hậu quả, vì các cơ sở dữ liệu cần phối hợp liên tục để đồng ý về những gì đã xảy ra.
Trong phân vùng, cả hai phía vẫn nhận yêu cầu. Nếu người dùng có thể ghi ở cả hai phía, mỗi phía có thể chấp nhận cập nhật mà phía kia không thấy.
Ví dụ: Nút A cập nhật địa chỉ người dùng thành “New Street.” Cùng lúc, Nút B cập nhật thành “Old Street Apt 2.” Mỗi phía tin rằng ghi của mình là mới nhất—vì không có cách nào để so sánh ngay.
Phân vùng không hiện ra dưới dạng thông báo lỗi gọn gàng; nó biểu hiện bằng hành vi gây bối rối:
Đây là điểm gây áp lực buộc phải chọn: khi mạng không đảm bảo giao tiếp, cơ sở dữ liệu phân tán phải quyết ưu tiên tính nhất quán hay khả dụng.
CAP là cách ngắn gọn để mô tả điều gì xảy ra khi cơ sở dữ liệu được trải trên nhiều máy.
Khi không có phân vùng, nhiều hệ thống có thể trông vừa nhất quán vừa khả dụng.
Khi có phân vùng, bạn phải chọn ưu tiên:\n
balance = 100 vào Server A.\n- 10:01 Phân vùng mạng: Server A không thể liên lạc Server B.\n- 10:02 Client đọc từ Server B.\n - Nếu bạn ưu tiên Nhất quán, Server B phải từ chối hoặc chờ.\n - Nếu bạn ưu tiên Khả dụng, Server B phản hồi, nhưng có thể trả balance = 80.CAP không có nghĩa là “chọn hai mãi mãi”. Nó nghĩa là khi có phân vùng, bạn không thể đảm bảo cả hai Nhất quán và Khả dụng cùng lúc. Ngoài phân vùng, nhiều hệ thống có thể tiến rất gần cả hai—cho tới khi mạng hành xử xấu.
Chọn nhất quán nghĩa là cơ sở dữ liệu ưu tiên “mọi người thấy cùng một chân lý” hơn là “luôn trả lời”. Thực tế thường hướng tới nhất quán mạnh, hay hành vi linearizable: khi một ghi được xác nhận, mọi lần đọc sau (từ bất cứ đâu) trả về giá trị đó, như thể chỉ có một bản sao luôn cập nhật.
Khi mạng tách và các bản sao không thể giao tiếp, hệ thống nhất quán mạnh không thể an toàn chấp nhận các cập nhật độc lập ở cả hai phía. Để bảo vệ đúng, nó thường:
Từ góc nhìn người dùng, điều này có thể trông như một đợt ngừng hoạt động mặc dù một số máy vẫn chạy.
Lợi ích chính là dễ suy luận hơn. Mã ứng dụng có thể hành xử như đang nói chuyện với một cơ sở dữ liệu đơn, không phải nhiều bản sao có thể bất đồng. Điều này giảm các “khoảnh khắc kỳ lạ” như:
Bạn cũng có mô hình tinh thần rõ ràng hơn cho kiểm toán, thanh toán, và mọi thứ phải đúng ngay từ lần đầu.
Nhất quán có chi phí thực tế:\n
Nếu sản phẩm của bạn không thể chịu các yêu cầu thất bại trong các gián đoạn một phần, nhất quán mạnh có thể cảm thấy đắt đỏ—dù đó là lựa chọn đúng để bảo đảm tính đúng đắn.
Chọn khả dụng nghĩa là tối ưu cho một lời hứa đơn giản: hệ thống trả lời, ngay cả khi một phần hạ tầng không khỏe. Trong thực tế, “cao khả dụng” không phải là “không bao giờ lỗi” mà là trong hầu hết trường hợp, yêu cầu vẫn nhận được phản hồi khi có lỗi nút, bản sao quá tải, hoặc liên kết mạng hỏng.
Khi mạng tách, các bản sao không thể giao tiếp tin cậy. Một cơ sở dữ liệu ưu tiên khả dụng thường tiếp tục phục vụ từ phía còn tiếp cận được:\n
Điều này giữ cho ứng dụng vận hành, nhưng cũng có nghĩa các bản sao khác nhau có thể tạm thời chấp nhận các chân lý khác nhau.
Bạn có thời gian hoạt động tốt hơn: người dùng vẫn có thể duyệt, thêm hàng vào giỏ, đăng bình luận, hoặc ghi sự kiện ngay cả khi một vùng bị cô lập.
Bạn cũng có trải nghiệm người dùng mượt hơn dưới áp lực. Thay vì timeout, app có thể tiếp tục với hành vi hợp lý (“cập nhật của bạn đã được lưu”) và đồng bộ sau. Với nhiều khối lượng người dùng tiêu dùng hoặc workloads phân tích, đánh đổi này đáng giá.
Giá phải trả là cơ sở dữ liệu có thể trả đọc cũ. Người dùng có thể cập nhật hồ sơ ở một bản sao, rồi ngay lập tức đọc ở bản sao khác và vẫn thấy giá trị cũ.
Bạn cũng đối mặt rủi ro xung đột ghi. Hai người dùng (hoặc cùng một người ở hai nơi) có thể cập nhật cùng một bản ghi ở hai phía phân vùng. Khi phân vùng lành, hệ thống phải hòa giải lịch sử phân kỳ. Tùy quy tắc, một trong các ghi có thể “thắng”, các trường có thể được gộp, hoặc xung đột có thể yêu cầu logic ứng dụng.
Thiết kế theo hướng khả dụng là chấp nhận bất đồng tạm thời để sản phẩm tiếp tục phản hồi—rồi đầu tư vào việc phát hiện và sửa chữa sau đó.
Quorum là kỹ thuật bỏ phiếu thực tế mà nhiều cơ sở dữ liệu sao chép dùng để cân bằng nhất quán và khả dụng. Thay vì tin vào một bản sao đơn lẻ, hệ thống hỏi đủ bản sao để đạt được đồng thuận.
Bạn thường thấy quorum mô tả bằng ba số:
Quy tắc thực tế: nếu R + W > N, thì mọi lần đọc sẽ chồng lấn với một ghi thành công trên ít nhất một bản sao, giảm khả năng đọc dữ liệu cũ.
Nếu bạn có N=3 bản sao:\n
Một số hệ thống tiến tới W=3 (tất cả các bản sao) để tăng nhất quán, nhưng điều đó có thể gây nhiều thất bại ghi khi bất kỳ bản sao nào chậm hay sập.
Quorum không loại bỏ vấn đề phân vùng—nó xác định ai được phép tiến hành. Nếu mạng chia 2–1, phía có 2 bản sao vẫn có thể thoả điều kiện R=2 và W=2, trong khi bản sao cô lập đơn lẻ thì không. Điều đó giảm cập nhật mâu thuẫn, nhưng đồng nghĩa một số client sẽ thấy lỗi hoặc timeout.
Quorum thường đồng nghĩa độ trễ cao hơn (phải liên hệ nhiều nút), chi phí cao hơn (nhiều lưu lượng liên nút), và hành vi lỗi tinh tế hơn (timeout trông giống không khả dụng). Lợi ích là một khoảng điều chỉnh: bạn có thể xoay R và W về phía đọc mới hơn hoặc ghi thành công nhiều hơn tùy điều gì quan trọng.
Tính nhất quán cuối cùng nghĩa là các bản sao được phép tạm thời không đồng bộ, miễn là chúng hội tụ về cùng một giá trị sau đó.
Hãy tưởng tượng một chuỗi tiệm cà phê cập nhật biển “hết hàng” cho một loại bánh. Một cửa hàng đánh dấu là hết hàng, nhưng cập nhật tới các cửa hàng khác chậm vài phút. Trong cửa sổ đó, cửa hàng khác có thể vẫn hiển thị “còn hàng” và bán cái cuối cùng. Hệ thống không “hỏng”—chỉ là cập nhật đang bắt kịp.
Khi dữ liệu đang được lan truyền, client có thể thấy các hành vi gây ngạc nhiên:\n
Hệ thống tính nhất quán cuối cùng thường thêm cơ chế nền để giảm cửa sổ không nhất quán:\n
Nó phù hợp khi khả dụng quan trọng hơn việc luôn cập nhật chính xác: feed hoạt động, bộ đếm lượt xem, gợi ý, hồ sơ được cache, log/telemetry, và các dữ liệu không quan trọng mà “đúng trong vài giây” là chấp nhận được.
Khi cơ sở dữ liệu chấp nhận ghi trên nhiều bản sao, nó có thể có xung đột: hai (hoặc nhiều) cập nhật cùng một mục xảy ra độc lập trên các bản sao khác nhau trước khi chúng đồng bộ.
Ví dụ kinh điển là một người dùng cập nhật địa chỉ trên thiết bị này trong khi thay đổi số điện thoại trên thiết bị khác. Nếu mỗi cập nhật rơi vào bản sao khác nhau trong lúc tạm mất kết nối, hệ thống phải quyết bản ghi “thực” là gì khi các bản sao trao đổi dữ liệu lại.
Nhiều hệ thống bắt đầu với last-write-wins: cập nhật có timestamp mới nhất ghi đè các cập nhật khác.
Điểm hấp dẫn là dễ triển khai và tính toán nhanh. Nhược điểm là có thể mất dữ liệu một cách im lặng. Nếu “mới nhất” thắng, một thay đổi cũ nhưng quan trọng có thể bị ghi đè—dù hai cập nhật tác động lên các trường khác nhau.
Nó cũng giả định đồng hồ tin cậy. Trượt đồng hồ giữa máy (hoặc client) có thể khiến cập nhật “sai” thắng.
Xử lý xung đột an toàn hơn thường yêu cầu theo dõi lịch sử nhân quả.
Ở mức khái niệm, version vector (và các biến thể đơn giản) gắn một mẩu metadata vào mỗi bản ghi để tóm tắt “bản sao nào đã thấy cập nhật nào.” Khi các bản sao trao đổi phiên bản, cơ sở dữ liệu có thể phát hiện xem một phiên bản chứa phiên bản kia hay không (không xung đột) hoặc chúng đã phân kỳ (xung đột cần giải quyết).
Một số hệ thống dùng timestamp logic (ví dụ Lamport clocks) hoặc hybrid logical clocks để giảm phụ thuộc vào thời gian thực tế trong khi vẫn cung cấp gợi ý thứ tự.
Khi phát hiện xung đột, bạn có lựa chọn:\n
Cách hay nhất phụ thuộc vào “đúng” nghĩa là gì cho dữ liệu của bạn—đôi khi mất một ghi là chấp nhận được, và đôi khi đó là lỗi nghiêm trọng về mặt nghiệp vụ.
Chọn tư thế nhất quán/khả dụng không phải là tranh luận triết học—đó là quyết định sản phẩm. Bắt đầu bằng câu hỏi: chi phí khi sai trong một khoảnh khắc là bao nhiêu, và chi phí khi nói “thử lại sau” là bao nhiêu?
Một số lĩnh vực cần câu trả lời duy nhất và có thẩm quyền khi ghi vì “gần đúng” vẫn là sai:\n
Nếu tác động của một sai lệch tạm thời thấp hoặc có thể đảo ngược, bạn thường nghiêng về khả dụng hơn.
Nhiều trải nghiệm người dùng ổn với đọc hơi cũ:\n
Hãy rõ ràng về cũ đến mức nào chấp nhận được: giây, phút hay giờ. Ngân sách thời gian đó quyết định lựa chọn sao chép và quorum của bạn.
Khi các bản sao không đồng ý, thường bạn có ba kết quả UX:\n
Chọn phương án tổn hại ít nhất cho từng tính năng, chứ không phải toàn hệ thống.
Nghiêng về C (nhất quán) nếu: kết quả sai tạo rủi ro tài chính/pháp lý, vấn đề bảo mật, hoặc hành động không thể đảo ngược.\n Nghiêng về A (khả dụng) nếu: người dùng đánh giá cao phản hồi nhanh, dữ liệu cũ chấp nhận được, và xung đột có thể được xử lý an toàn sau.
Khi lăn tăn, tách hệ thống: giữ bản ghi quan trọng ở chế độ nhất quán mạnh, và để các view phái sinh (feed, cache, analytics) tối ưu cho khả dụng.
Bạn hiếm khi phải chọn một “cài đặt nhất quán” cho toàn hệ thống. Nhiều cơ sở dữ liệu phân tán hiện đại cho phép chọn mức nhất quán theo thao tác—và ứng dụng thông minh tận dụng điều đó để giữ UX mượt mà mà không giả vờ đánh đổi không tồn tại.
Xem tính nhất quán như một núm bạn vặn theo hành động người dùng:\n
Điều này tránh phải trả chi phí nhất quán mạnh cho mọi thứ, đồng thời vẫn bảo vệ những thao tác cần nó.
Mẫu phổ biến là mạnh cho ghi, yếu cho đọc:\n
Trong một số trường hợp, ngược lại cũng hợp lý: ghi nhanh (đặt hàng vào hàng đợi / cuối cùng) cộng đọc mạnh khi xác nhận kết quả (“Đơn hàng của tôi đã đặt chứ?”).
Khi mạng rung lắc, client retry. Làm cho thử lại an toàn bằng idempotency keys để “gửi đơn” hai lần không tạo ra hai đơn. Lưu và tái sử dụng kết quả đầu tiên khi thấy cùng khóa.
Với hành động đa bước qua nhiều dịch vụ, dùng saga: mỗi bước có hành động bù đắp tương ứng (hoàn tiền, giải phóng giữ chỗ, hủy vận chuyển). Điều này làm cho hệ thống có thể khôi phục ngay cả khi các phần tạm thời bất đồng hoặc thất bại.
Bạn không thể quản lý đánh đổi nếu không nhìn thấy nó. Vấn đề sản xuất thường trông như “lỗi ngẫu nhiên” cho tới khi bạn thêm đo lường và kiểm thử đúng.
Bắt đầu với một tập nhỏ chỉ số liên quan trực tiếp đến trải nghiệm người dùng:\n
Nếu có thể, gắn tag chỉ số theo chế độ nhất quán (quorum vs cục bộ) và region/zone để phát hiện nơi hành vi lệch.
Đừng chờ tới sự cố thật. Ở staging, chạy các thí nghiệm hỗn loạn mô phỏng:\n
Xác minh không chỉ “hệ thống còn chạy”, mà các đảm bảo nào vẫn giữ: đọc còn tươi, ghi có chặn, client nhận lỗi rõ ràng?
Thêm cảnh báo cho:\n
Cuối cùng, làm rõ các cam kết: tài liệu hóa điều hệ thống hứa trong hoạt động bình thường và khi phân vùng, và huấn luyện nhóm sản phẩm và hỗ trợ về những gì người dùng có thể thấy và cách phản ứng.
Nếu bạn đang khám phá những đánh đổi này cho sản phẩm mới, tốt nhất là kiểm chứng giả định sớm—đặc biệt về chế độ lỗi, hành vi retry, và “cũ” trông như thế nào trên giao diện.
Một cách thực tế là nguyên mẫu một phiên bản nhỏ của luồng (đường ghi, đường đọc, retry/idempotency, và một job hòa giải) trước khi cam kết kiến trúc toàn bộ. Với Koder.ai, các đội có thể dựng nhanh web app và backend qua giao diện chat, lặp nhanh trên mô hình dữ liệu và API, và thử các mẫu nhất quán khác nhau (ví dụ ghi nghiêm ngặt + đọc lỏng) mà không cần overhead của quy trình build truyền thống. Khi nguyên mẫu phù hợp, bạn có thể xuất mã nguồn và phát triển thành sản phẩm.
Trong một cơ sở dữ liệu sao chép, “cùng” dữ liệu tồn tại trên nhiều máy. Điều này tăng khả năng chịu lỗi và có thể giảm độ trễ, nhưng đồng thời tạo ra vấn đề phân phối: các nút có thể chậm, không thể truy cập, hoặc bị tách ra bởi mạng, nên không luôn luôn đồng ý ngay lập tức về ghi gần nhất.
Nhất quán nghĩa là: sau một lần ghi thành công, mọi lần đọc sau đó trả về đúng giá trị đó—bất kể bản sao nào phục vụ truy vấn. Trong thực tế, các hệ thống thường thực thi điều này bằng cách trì hoãn hoặc từ chối đọc/ghi cho đến khi đủ các bản sao (hoặc leader) xác nhận cập nhật.
Khả dụng nghĩa là hệ thống trả về một phản hồi không lỗi cho mọi yêu cầu, ngay cả khi một vài nút bị hỏng hoặc không thể giao tiếp. Phản hồi có thể là dữ liệu cũ, chỉ một phần, hoặc dựa trên thông tin cục bộ, nhưng hệ thống tránh chặn người dùng trong khi có sự cố.
Phân vùng mạng là sự gián đoạn trong liên lạc giữa các nút lẽ ra hoạt động như một hệ thống thống nhất. Các nút vẫn có thể chạy bình thường, nhưng tin nhắn không thể truyền qua vùng chia cắt một cách đáng tin cậy, buộc cơ sở dữ liệu phải chọn giữa:
Trong thời gian phân vùng, mỗi phía có thể chấp nhận các cập nhật mà phía kia chưa thấy. Điều này có thể dẫn tới:
Đây là hậu quả dễ nhìn thấy khi các bản sao tạm thời không thể phối hợp.
Không. Nó không có nghĩa là “chọn hai trong ba” mãi mãi. Ý nghĩa của CAP là khi xảy ra phân vùng, bạn không thể đảm bảo đồng thời:
Ngoài phân vùng, nhiều hệ thống trông như thể cung cấp cả hai tính chất hầu hết thời gian—cho tới khi mạng gặp vấn đề.
Quorum dùng cơ chế bỏ phiếu giữa các bản sao:
Nguyên tắc thông thường là R + W > N để giảm khả năng đọc dữ liệu cũ. Quorum không loại trừ phân vùng; nó xác định phía nào có thể tiếp tục tiến (ví dụ phía có đa số).
Tính nhất quán cuối cùng cho phép các bản sao tạm thời không đồng bộ miễn là chúng hội tụ về cùng một giá trị sau đó. Những hiện tượng thường thấy gồm:
Hệ thống thường giảm thiểu bằng , , và cơ chế định kỳ.
Xung đột xảy ra khi các bản sao chấp nhận các ghi khác nhau cho cùng một mục trong lúc bị ngắt. Các chiến lược giải quyết gồm:
Chọn chiến lược tùy theo ý nghĩa “đúng” của dữ liệu của bạn.
Quyết định dựa trên rủi ro kinh doanh và hậu quả của lỗi tạm thời so với việc từ chối yêu cầu:
Mô hình thực tế: đặt mức nhất quán theo từng thao tác, dùng idempotency cho retry, và áp dụng saga cho luồng dài.