Eventual Consistency và Strong Consistency trong Cơ sở dữ liệu phân tán
Last updated: August 24, 2025 Xem trên toàn màn hình
Recommended for you
- 03 May 2019
Business Rule là gì? 886 - 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 587
- 01 Feb 2023 Information Radiator là gì? 578
- 18 May 2021 Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 521
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 424
- 03 May 2022 Mô hình Hybrid Agile là gì? 409
- 18 Mar 2021 Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 380
- 02 Aug 2023 Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 328
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 311
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 306
- 29 May 2022 Templafy là gì? Tại sao nói Templafy là nền tảng tài liệu thế hệ mới? 303
- 01 May 2021 Unit Test là gì? 300
- 01 Aug 2023 Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 293
- 28 Jun 2024 Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 257
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 247
- 02 Mar 2018 Tại sao ví Scrum như dòng điện xoay chiều? 232
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 191
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 175
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 162
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 154
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 152
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 140
- 10 Aug 2020 Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward 90
- 22 Jul 2020 Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 86
- 04 Feb 2022 Phân biệt lập trình viên (programmer) và kỹ sư phần mềm (software engineer) 58
- 11 Mar 2025 Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 49
- 04 Mar 2025 So sánh các giải pháp Sales Loft, Power BI và Salesforce 40
- 29 Aug 2023 Phân biệt Accountable và Responsible? 36
- 01 Jun 2025 Thiết Kế Hướng Miền (Domain-Driven Design) hình thành như thế nào trong kiến trúc Lưới Dữ Liệu (Data Mesh)? 32
- 19 Mar 2023 Post-mortem và Retrospective: Khác biệt là gì? 29
- 29 Jul 2023 Giải mã 10 "Pain Points" của Big Data: Khi "mỏ vàng dữ liệu" vẫn không thể khai thác 29
- 09 Aug 2024 Latency (độ trễ) là gì? 27
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 25
- 01 Apr 2025 CTO ra quyết định như thế nào? 21
- 15 May 2025 Hiệu quả năng lượng trong phần mềm (Energy Efficiency in Software) là gì? 14
- 01 Nov 2022 MVF (Minimum Viable Features): Tối ưu tính năng trong giới hạn nguồn lực 14
- 13 Apr 2025 Phân biệt MLP (Minimum Lovable Product) và State-of-the-art Product 14
- 09 Aug 2023 "Loop unrolling" là gì? 13
- 29 Aug 2023 "Function inlining" là gì? 13
- 05 Aug 2025 "Nói láo" khác với "nói dối" như thế nào? 12
- 08 Aug 2024 Phân biệt mô hình MLP với mô hình BVP 10
- 30 Apr 2024 Web3 là gì? Tại sao nói Web3 là nền tảng để Blockchain thay đổi Internet? 3
- 08 Aug 2023 "Denormalized Table" là gì?
Một Database Transaction, theo định nghĩa, phải đảm bảo bốn tính chất: Atomic, Consistency, Isolation và Durable (ACID). Trong bối cảnh microservices và hệ thống phân tán, tính nhất quán (Consistency) trở thành yếu tố đặc biệt quan trọng bởi dữ liệu được nhân bản và lưu trữ trên nhiều node khác nhau. Ở đây, chúng ta sẽ tập trung phân tích Consistency, đồng thời làm rõ sự khác biệt giữa Eventual Consistency và Strong Consistency thông qua các ví dụ gần gũi trong đời sống, từ đó thấy được vì sao việc lựa chọn mô hình nhất quán phù hợp là cốt lõi trong thiết kế microservices.
Việc giải thích chủ đề này bắt đầu bằng một phép ẩn dụ, lấy ví dụ từ đời sống thực để hiểu khái niệm dễ hơn.
Tôi có thói quen ghi lại những thứ mà tôi gọi là Tech Notes trên laptop hằng ngày để tóm tắt các khái niệm kỹ thuật mình học được. Điều này giúp tôi dễ dàng nhớ lại chúng bất cứ khi nào cần.
Nhưng đôi khi tôi lo lắng laptop bị mất cắp hoặc hỏng. Vì sợ mất Tech Notes, tôi bắt đầu sao lưu chúng vào ổ cứng ngoài. Để giảm rủi ro hơn nữa, tôi còn mua thêm gói dịch vụ Dropbox.
Cứ nửa tháng một lần, tôi cập nhật ổ cứng ngoài với những Tech Notes mới hoặc chỉnh sửa, còn Dropbox thì được cập nhật ngay khi laptop kết nối Internet.
Ở đây, tôi dùng ổ cứng ngoài và Dropbox làm nguồn đọc Tech Notes, trong khi laptop vừa dùng để đọc vừa để viết. (Mô hình Master-Slave).
Bây giờ, hãy đi thẳng vào vấn đề.
Trường hợp 1: Eventual Consistency
Eventual consistency (tính nhất quán cuối cùng) là một mô hình trong hệ thống phân tán, trong đó dữ liệu có thể tạm thời không đồng bộ giữa các nút, nhưng theo thời gian nếu không có thêm thay đổi mới, tất cả các bản sao dữ liệu sẽ dần trở nên nhất quán. Nói cách khác, hệ thống chấp nhận trạng thái “không nhất quán tạm thời” để đổi lấy hiệu năng và khả năng mở rộng, với cam kết rằng cuối cùng dữ liệu sẽ được đồng bộ. Mô hình này thường được áp dụng trong các hệ thống lớn như cơ sở dữ liệu NoSQL hoặc dịch vụ lưu trữ đám mây.
Khi ta sử dụng nhiều bản sao (replica) của cơ sở dữ liệu để lưu trữ dữ liệu, giả sử có một yêu cầu ghi (write request) đến một trong các replica. Trong tình huống này, cơ sở dữ liệu phải có cơ chế để bản ghi đó được truyền đến các replica khác, để tất cả chúng cùng lưu dữ liệu và trở nên nhất quán (consistent).
Nhất quán (Consistency) ở đây nghĩa là: bất cứ yêu cầu đọc (read request) nào tới bất kỳ node nào trong cơ sở dữ liệu cũng phải trả về cùng một dữ liệu.
Eventual consistency đảm bảo rằng dữ liệu trên các node cuối cùng rồi cũng sẽ trở nên nhất quán. Thời gian để các node đồng bộ có thể được xác định hoặc không.
Điều này có nghĩa là sẽ mất thời gian để các bản cập nhật lan tỏa đến các replica khác. Vậy thì sao? Nếu ai đó đọc từ một replica chưa kịp cập nhật (vì các replica chỉ cập nhật dần dần), thì dữ liệu trả về có thể là dữ liệu cũ (stale data).
Ổ cứng ngoài của tôi cũng giữ dữ liệu cũ trong vòng 15 ngày, bởi nó chỉ được cập nhật nửa tháng một lần. Giả sử vài ngày sau khi tôi cập nhật, bạn tôi – John – đến và hỏi mượn ổ cứng ngoài:
- John: Tôi muốn mượn ổ cứng của cậu để đọc Tech Notes.
- Tôi: Được thôi, nhưng nó chưa được cập nhật mấy ngày rồi.
- John: Không sao đâu.
Như vậy, ổ cứng ngoài được đưa cho John ngay lập tức (độ trễ thấp) nhưng có rủi ro là dữ liệu cũ. Tuy nhiên, tôi chắc chắn rằng nó sẽ được cập nhật khi tới kỳ nửa tháng tiếp theo.
Trường hợp 2: Strong Consistency
(nhất quán mạnh)
Strong consistency quy định rằng dữ liệu phải được truyền đến tất cả các replica ngay khi có một yêu cầu ghi đến một replica của cơ sở dữ liệu.
Nhưng trong lúc các replica đang bận cập nhật dữ liệu mới, tất cả các yêu cầu đọc/ghi tiếp theo sẽ bị trì hoãn, vì các replica cần ưu tiên đồng bộ dữ liệu với nhau trước.
Khi các replica đã trở nên nhất quán, chúng mới tiếp tục xử lý các yêu cầu mới.
Lần này, bạn tôi – Veronica – đến và hỏi xin Tech Notes:
- Veronica: Tôi muốn có Tech Notes mới nhất của cậu.
- Tôi: Được thôi, tôi sẽ chia sẻ cho cậu link Dropbox. Nhưng Veronica này, hãy chờ vài phút nhé, vì tôi vừa viết một Tech Note mới trên laptop, nó sẽ đồng bộ với tài khoản Dropbox của tôi trong 2–3 phút nữa.
Kết quả là Veronica đã có thể truy cập Tech Notes mới nhất, nhưng phải chờ thêm vài phút.
Kết luận
- Strong Consistency: dữ liệu luôn mới nhất, nhưng đi kèm độ trễ cao.
- Eventual Consistency: độ trễ thấp, nhưng có thể trả về dữ liệu cũ vì không phải tất cả node đều cập nhật kịp thời.
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
Mới cập nhật
