etcd: kho khóa-giá trị đồng thuận Raft và bài toán điều phối cho khách sạn ven biển Đà Nẵng
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Tóm tắt: etcd là bộ nhớ đồng thuận cho hệ thống phân tán, không phải cơ sở dữ liệu đa dụng
etcd là một kho dữ liệu khóa-giá trị (key-value store) phân tán. README mô tả nó là nơi lưu "dữ liệu quan trọng nhất của một hệ thống phân tán", với bốn định hướng: giao diện gRPC rõ ràng, bảo mật bằng TLS, tốc độ và độ tin cậy nhờ thuật toán đồng thuận Raft. Mã nguồn viết bằng Go, và README cho biết etcd thường được dùng cùng Kubernetes cùng nhiều ứng dụng khác. [1]
Khuyến nghị của bài viết rất cụ thể: hãy xem etcd như một thành phần điều phối nhỏ nhưng đòi hỏi kỷ luật vận hành. Nó phù hợp với cấu hình dùng chung, bầu chọn bản chính (leader election), khóa phân tán và theo dõi thay đổi. Nó không nên là nơi chứa dữ liệu nghiệp vụ lớn. Đây là nhận định rút ra từ mô hình bảo mật và tài liệu kiểm thử độ bền của dự án, không phải kết quả đo đạc của người viết. [4][6]
Bài viết đề xuất một tình huống giả định cho khách sạn ven biển Đà Nẵng. Kết luận ngắn gọn: đa số khách sạn không cần tự chạy etcd, vì nó đã nằm sẵn bên trong nền tảng Kubernetes quản lý hoặc phần mềm đóng gói. Chỉ khi đội kỹ thuật tự xây dịch vụ đồng bộ phòng và giá cho nhiều cơ sở thì mới nên cân nhắc dùng trực tiếp. Cần lưu ý nhánh main có thể ở trạng thái không ổn định, nên chỉ dùng các bản phát hành. [1]
Bài toán gốc: nhiều tiến trình cùng cần một sự thật duy nhất
Khi một ứng dụng chạy trên nhiều máy, các bản sao dịch vụ phải thống nhất vài điều rất nhỏ nhưng không được sai: ai đang giữ vai trò chính, cấu hình nào đang có hiệu lực, một khóa đã có chủ hay chưa. Nếu lưu chúng trong tệp dùng chung, hai tiến trình có thể cùng tin mình là bản chính, và hậu quả là tác vụ chạy hai lần hoặc ghi đè nhau.
etcd nhắm đúng khoảng trống này. Theo README, dữ liệu được quản lý bằng một nhật ký nhân bản có tính sẵn sàng cao dựa trên Raft, còn máy khách làm việc qua một API gRPC thống nhất. [1] Tài liệu kiểm thử độ bền (robustness) nêu rõ các bảo đảm dự án muốn giữ: strict serializability (tuần tự hóa chặt) cho thao tác khóa-giá trị và eventual consistency (nhất quán cuối cùng) cho watch, tức cơ chế theo dõi thay đổi. [6]
Điều etcd không làm thay bạn cũng quan trọng không kém: nó không phải kho đối tượng, không phải cơ sở dữ liệu quan hệ và không có ngôn ngữ truy vấn nghiệp vụ. Các tài liệu đã đọc không nêu giới hạn dung lượng, nên bài viết không khuyến nghị dùng etcd cho khối dữ liệu nghiệp vụ lớn. [1]
Raft, nhật ký ghi trước và kho nền: bốn lớp của một cụm etcd
Lớp đầu tiên là giao diện máy khách. README nêu hai cổng chính thức: 2379 cho yêu cầu của máy khách và 2380 cho liên lạc giữa các thành viên. [1] Phía Go có thư viện client v3 cài bằng một lệnh go get, và công cụ dòng lệnh etcdctl dùng để đọc ghi thử. Danh sách tài liệu API trong README còn liệt kê các module riêng cho api, client, etcdctl, pkg, raft và server, cho thấy dự án chia thành nhiều module độc lập. [1]
Lớp thứ hai là đồng thuận. Các thành viên trao đổi qua cổng 2380 để chạy Raft và giữ một nhật ký nhân bản. Ví dụ cụm cục bộ trong README dùng ba thành viên, kèm tùy chọn grpc-proxy, và nhắc việc thêm nút learner (thành viên chưa tham gia biểu quyết). [1] Roadmap cho biết etcd 3.6.0 phụ thuộc vào thư viện raft và bbolt phát hành riêng, nghĩa là hai thành phần này có vòng đời tách khỏi kho mã chính. [5]
Lớp thứ ba và thứ tư là lưu trữ. Báo cáo sau sự cố v3.5 giải thích trạng thái etcd v3 nằm ở hai dạng: write ahead log (WAL, nhật ký ghi trước) lưu lịch sử thay đổi, và cơ sở dữ liệu (DB) biểu diễn trạng thái tại một thời điểm. DB giữ thêm một trường siêu dữ liệu gọi là consistent index, trỏ tới mục WAL cuối cùng đã áp dụng. [7]
Từ lệnh put đến trạng thái đã ghi: đường đi của một thay đổi
Hãy theo dõi một lệnh ghi đơn giản. README minh họa bằng etcdctl put mykey rồi etcdctl get mykey trên một cụm một thành viên đang lắng nghe cổng 2379. [1] Với cụm nhiều thành viên, mô tả khái quát về Raft như sau: yêu cầu ghi trở thành một đề xuất, được nhân bản sang các thành viên khác qua cổng 2380, và chỉ được xem là đã cam kết khi đa số xác nhận. Phần này dựa trên thuật toán Raft nói chung, không phải đọc mã nguồn.
Sau khi cam kết, mỗi thành viên phát lại các mục WAL vào cơ sở dữ liệu của mình và cập nhật consistent index. Báo cáo sự cố v3.5 nhấn mạnh thao tác này bắt buộc nguyên tử. Nếu chỉ cập nhật chỉ số, một số mục bị bỏ qua. Nếu chỉ áp dụng thay đổi, chúng bị thực hiện hai lần. Mọi thành viên phải đi tới cùng một trạng thái khi phát lại cùng một chuỗi mục. [7]
Mỗi trạng thái được gắn với một revision, tức số phiên bản của kho khóa-giá trị. Cơ chế phát hiện sai lệch dựa trên việc so sánh hash của dữ liệu tại cùng một revision giữa các thành viên qua lời gọi HashKV. [7]
Những gì nguồn chính thức xác nhận được ở commit khảo sát
Về tính năng hiện có, README xác nhận giao diện gRPC, TLS với xác thực chứng chỉ máy khách tùy chọn, nhân bản bằng Raft, client Go v3, công cụ etcdctl, cụm ba thành viên chạy cục bộ và khả năng thêm learner. [1] Cũng theo README, dự án có chương trình kiểm thử robustness, và con số "10.000 lượt ghi mỗi giây" xuất hiện ở dạng lời giới thiệu, không kèm cấu hình phần cứng hay phương pháp đo. Bài viết không dùng con số này làm bằng chứng hiệu năng. [1]
Roadmap ghi nhận các hạng mục đã hoàn tất như hỗ trợ hạ cấp từ 3.6.0, các endpoint /livez và /readyz, công cụ phẫu thuật tệp db của bbolt, và trong mốc 3.7 là khởi động máy chủ từ v3store cùng tính năng range stream. [5] Tài liệu threat model bổ sung rằng binary được biên dịch tĩnh thuần Go với CGO_ENABLED=0. [4]
Phần kế hoạch và chưa chắc chắn cần tách riêng. Roadmap liệt kê cho mốc 3.8 việc xây bộ kiểm tra hiệu năng chính thức (ưu tiên P1), tích hợp ghi bất đồng bộ của raft (còn tạm thời, cần nghiên cứu) và đánh giá thay cmux. Danh sách tồn đọng có hỗ trợ xoay vòng CA và tracing bằng OpenTelemetry. [5] Tuy vậy threat model lại nhắc đến cờ distributed tracing, vì thế roadmap có thể đã chậm so với mã. Người dùng nên đối chiếu với ghi chú phát hành của phiên bản định dùng. [4][5]
Ai nên đọc tiếp, ai có thể dừng ở đây
Nhóm hưởng lợi rõ nhất là đội nền tảng hoặc SRE đang vận hành Kubernetes hay các hệ thống phân tán tự xây. README nói etcd thường đi cùng Kubernetes, còn threat model cho biết Kubernetes API server là một trong những người dùng lớn dựa vào bảo mật tầng truyền tải và cô lập mạng thay cho kiểm soát truy cập tích hợp. [1][4]
Nhóm thứ hai là lập trình viên viết dịch vụ cần bầu chọn leader, khóa hay cấu hình động; họ nên đọc cam kết nhất quán của API trước khi dựa vào nó. [6]
Nếu bạn chỉ cần lưu hồ sơ khách hay đơn hàng, etcd không phải thứ cần chọn; các nhu cầu đó thuộc về cơ sở dữ liệu nghiệp vụ. README dẫn tới tệp ADOPTERS.md, nhưng bài viết không đọc tệp này nên không dùng nó làm bằng chứng. [1]
Tình huống giả định: chuỗi khách sạn ven biển Đà Nẵng và bộ đồng bộ giá phòng
Đây là một đề xuất, không phải trường hợp đã triển khai. Giả sử một nhóm ba khách sạn ven biển Đà Nẵng tự phát triển lớp dịch vụ nội bộ chạy trên Kubernetes để đồng bộ tồn phòng và giá giữa phần mềm quản lý khách sạn (PMS), trang đặt phòng riêng và các kênh bán. Hệ thống đặt phòng gốc vẫn nằm trong PMS và cơ sở dữ liệu quan hệ. etcd chỉ giữ những dữ kiện điều phối rất nhỏ.
Ba việc phù hợp với etcd là: bầu chọn một worker duy nhất được phép đẩy giá lên các kênh, khóa ngắn hạn cho thao tác điều chỉnh số phòng của một loại phòng trong một ngày, và cờ cấu hình cho các đợt khuyến mại mùa cao điểm. Khi worker mất liên lạc với cụm, nó phải dừng đẩy giá thay vì tiếp tục với dữ liệu cũ. Một báo cáo kiểm thử độ bền cho thấy etcd từng có lỗi đọc dữ liệu cũ khi tiến trình bị tạm dừng, nên khóa cần kèm fencing token (số thứ tự tăng dần mà bên nhận kiểm tra). [6]
Về hạ tầng, đề xuất đặt ba thành viên ở ba miền lỗi khác nhau: hai phòng máy và một máy ảo đám mây. Mùa mưa bão miền Trung dễ gây mất điện hoặc đứt cáp; theo cơ chế đa số của Raft, cụm ba nút vẫn phục vụ khi mất một nút. Độ trễ giữa các địa điểm phải được đo trong giai đoạn thử, vì nguồn đã đọc không có số liệu này.
Vận hành: số lượng thành viên, giám sát và những điều README chưa nói
README cho biết có sẵn bản nhị phân dựng sẵn cho macOS, Linux, Windows và Docker trên trang phát hành, còn hướng dẫn vận hành, cấu hình và tuning nằm ở etcd.io. [1] Bài viết chưa đọc các trang đó, vì vậy quy trình sao lưu, khôi phục, cấu hình bộ nhớ và kích thước đĩa không được mô tả ở đây. Hãy đọc chúng theo đúng phiên bản định dùng. [1]
Một bài học vận hành đến từ báo cáo sự cố v3.5: với cụm một thành viên, sai lệch giữa WAL và cơ sở dữ liệu hoàn toàn không phát hiện được, vì không có công cụ đối chiếu. Cụm nhiều thành viên có cơ chế kiểm tra hash khi khởi động và định kỳ, qua các cờ thử nghiệm được nêu tại thời điểm viết báo cáo, nhưng kiểm tra này phụ thuộc HashKV và có thể bỏ sót. [7] Trạng thái hiện tại của các cờ chưa được xác minh ở đây. Vì vậy môi trường quan trọng nên chạy ít nhất ba thành viên.
Roadmap cho thấy các điểm hỗ trợ vận hành đã có hoặc sắp có: /livez và /readyz giúp kiểm tra sức khỏe rõ hơn, hỗ trợ hạ cấp từ 3.6.0, và nhật ký cùng lệnh phẫu thuật cho bbolt để chẩn đoán tệp hỏng. [5] Bài viết khuyến nghị thêm giám sát độ trễ ghi và cảnh báo mất đa số; đây là ý kiến của người viết, không trích từ tài liệu.
Ranh giới tin cậy theo THREAT_MODEL: mạng kín, mTLS và dữ liệu không mã hóa sẵn
Tài liệu THREAT_MODEL nói rõ etcd phải chạy trong một phân đoạn mạng riêng tư, bị cô lập, và không được phơi ra Internet hay mạng không tin cậy. Cổng 2379 của máy khách yêu cầu mTLS (xác thực hai chiều bằng chứng chỉ). Cổng 2380 giữa các thành viên cũng chỉ dành cho thành viên được cấp chứng chỉ peer riêng. Chứng chỉ bị đánh cắp nằm ngoài mô hình đe dọa. [4]
Kiểm soát truy cập theo vai trò (RBAC) có sẵn nhưng chỉ là lớp phụ tùy chọn, mặc định tắt. Với watch, việc thu hồi quyền có tính nhất quán cuối cùng theo thiết kế, nên luồng đã mở có thể còn nhận sự kiện trong một khoảng ngắn. [4] Về dữ liệu nghỉ, etcd ghi dữ liệu xuống đĩa đúng như nhận được; bảo vệ khi lưu trữ thuộc trách nhiệm của máy khách, qua mã hóa phong bì, hoặc của mã hóa đĩa. Vì vậy dữ liệu cá nhân của khách lưu trú không nên đưa vào etcd khi chưa mã hóa. [4]
Phạm vi trả lời lỗ hổng cũng có giới hạn. Grpc-proxy, gói cache và mọi thứ trong contrib chỉ được hỗ trợ theo nỗ lực tốt nhất, không thuộc quy trình phản hồi bảo mật. Tệp SECURITY.md ở thư mục .github chỉ dẫn người đọc tới security/README.md để biết cách báo cáo lỗ hổng. [3]
Apache 2.0 cho mã ở commit này, và ba điều giấy phép không nói thay bạn
Tệp LICENSE ở gốc kho là văn bản Apache License 2.0. Giấy phép này cấp quyền sử dụng, sửa đổi và phân phối kèm điều khoản cấp phép sáng chế ở mục 3, đồng thời mục 6 nói rõ giấy phép không cấp quyền dùng nhãn hiệu, tên thương mại hay tên sản phẩm. [2] Bài viết dựa vào văn bản LICENSE chứ không chỉ vào trường giấy phép của API GitHub.
Cây thư mục tại commit khảo sát có thêm các tệp LICENSE ở nhiều thư mục con như api, client, etcdctl, etcdutl, pkg, server và tests. Bài viết chưa đọc nội dung từng tệp, nên không khẳng định chúng giống hệt tệp gốc. Ai cần tuân thủ pháp lý chặt chẽ phải kiểm tra từng module. Yêu cầu đóng góp như CLA không nằm trong nguồn đã đọc.
Ranh giới thứ ba là phạm vi: giấy phép này áp dụng cho mã nguồn ở commit đã ghim, không tự động áp dụng cho các thư viện phụ thuộc, hình ảnh container do bên khác dựng, bản phân phối của nhà cung cấp đám mây, hay Kubernetes. Bản fork hoặc dịch vụ bọc quanh etcd có thể có điều khoản riêng. Đây là phân tích tuân thủ sơ bộ, không phải tư vấn pháp lý.
Chi phí và nguồn lực: ba nút nhỏ, một người biết vận hành, và thời gian học
Bài viết không đưa giá tiền, vì tài liệu đã đọc không có bảng giá và giá hạ tầng thay đổi theo nhà cung cấp. Thay vào đó là các loại nguồn lực. Với cụm thử nghiệm ba thành viên cần ba máy hoặc máy ảo nhỏ, đĩa có độ trễ ghi ổn định, kết nối mạng đáng tin giữa các địa điểm, chứng chỉ TLS cùng quy trình cấp phát và gia hạn, và hệ thống giám sát có cảnh báo.
Nguồn lực con người thường lớn hơn phần cứng: cần người hiểu Raft đủ để đọc nhật ký khi mất đa số, người phụ trách nâng cấp theo phiên bản, và thời gian kiểm thử các kịch bản ngắt mạng.
Phương án thay thế về chi phí là dùng Kubernetes quản lý, nơi nhà cung cấp lo etcd. Khi đó chi phí chuyển thành phí dịch vụ và mất khả năng tùy chỉnh. Mã nguồn etcd miễn phí theo Apache 2.0 nhưng điều đó không đồng nghĩa với tổng chi phí sở hữu thấp, vì roadmap cho biết nhóm duy trì tập trung vào nợ kỹ thuật và dựa theo năng lực bảo trì hiện có. [2][5]
So sánh các hướng: etcd, dịch vụ điều phối khác, khóa trong cơ sở dữ liệu và dịch vụ quản lý
Ở mức cách tiếp cận, có bốn hướng. Thứ nhất, tự chạy etcd để có API khóa-giá trị, watch và lease thống nhất, đổi lại gánh vận hành cụm đồng thuận. Thứ hai, dùng dịch vụ điều phối cùng loại như Apache ZooKeeper hoặc HashiCorp Consul, mỗi cái có mô hình dữ liệu và hệ sinh thái riêng. Bài viết không so sánh hiệu năng giữa chúng vì nguồn đã đọc không có số liệu.
Thứ ba, dùng cơ chế khóa của cơ sở dữ liệu quan hệ đang có. Cách này ít thành phần hơn và hợp với đội nhỏ, nhưng độ sẵn sàng của khóa phụ thuộc vào chính cơ sở dữ liệu đó. Thứ tư, dùng dịch vụ quản lý của nhà cung cấp đám mây để chuyển trách nhiệm vận hành đi.
Tiêu chí chọn nên là mức độ nghiêm trọng khi hai tiến trình cùng làm một việc, số địa điểm vật lý và kỹ năng sẵn có. Với dịch vụ chỉ có một cơ sở, khóa trong cơ sở dữ liệu có thể là đủ. Khi cần liên kết nhiều địa điểm và có đội kỹ thuật riêng, etcd trở nên đáng thử, nhất là nhờ kho kiểm thử độ bền mà dự án công bố. [6]
Hạn chế và những điều kiện không nên dùng
Điều kiện loại trừ đầu tiên là không thể đảm bảo mạng kín: nếu etcd phải tiếp xúc Internet hoặc mạng khách, THREAT_MODEL xem đó là cách triển khai sai chứ không phải lỗi của dự án. [4] Điều kiện thứ hai là khi không có người vận hành hiểu cụm đồng thuận, vì mất đa số làm dịch vụ ngừng ghi, điều này suy ra từ cơ chế Raft chứ không phải số liệu đo.
Lịch sử lỗi công khai cũng cần được tính đến. Bảng theo dõi của kiểm thử robustness liệt kê nhiều lỗi nhất quán và watch, chẳng hạn đọc dữ liệu cũ do tiến trình tạm dừng, sự kiện watch bị mất khi nén dữ liệu, hay lùi revision sau khi sập lúc compaction. [6] Việc công bố minh bạch là điểm cộng, nhưng cũng nhắc rằng cần cập nhật bản vá. Sự cố v3.5 cho thấy lỗi có thể xuất hiện từ một lần tái cấu trúc mã. [7]
Cuối cùng, một số thành phần phụ chỉ được hỗ trợ theo nỗ lực tốt nhất, và roadmap nêu năng lực bảo trì có thể thay đổi. [4][5] Không nên chọn etcd nếu bạn cần truy vấn phức tạp, lưu tệp lớn, mã hóa dữ liệu nghỉ sẵn có hay một giải pháp không cần ai vận hành.
Kế hoạch thử nghiệm trong tám tuần, có tiêu chí dừng
Giai đoạn một, hai tuần, dựng cụm ba thành viên trong môi trường thử, dùng bản phát hành ổn định và bật mTLS cho cổng 2379 và 2380. Tiêu chí hoàn thành: máy khách kết nối được khi có chứng chỉ, bị từ chối khi không có, và có quy trình cấp, gia hạn chứng chỉ bằng văn bản.
Giai đoạn hai, ba tuần, cài bộ đồng bộ giá giả lập với bầu chọn leader. Các kịch bản gồm tắt một thành viên, ngắt liên lạc giữa các địa điểm, tạm dừng tiến trình worker và khởi động lại hàng loạt. Tiêu chí đề xuất: tại mọi thời điểm không quá một worker đẩy giá, và worker mất liên lạc phải ngừng trong ngưỡng thời gian mà nhóm tự đặt trước, ví dụ vài giây. Phép đo là của đội thử nghiệm, không phải con số trích từ dự án.
Giai đoạn ba, ba tuần, chạy song song ở chế độ chỉ ghi nhận rồi so sánh với PMS. Tiêu chí dừng: có bất kỳ trường hợp hai worker cùng đẩy giá, mất dữ liệu cấu hình, hoặc nhóm không thực hiện được quy trình sao lưu và khôi phục theo tài liệu vận hành. Khi đó chuyển sang dịch vụ quản lý hoặc khóa trong cơ sở dữ liệu. Trước khi mở rộng, đối chiếu lại roadmap. [5]
Kết luận: một thành phần quan trọng, nhỏ và không dành cho mọi đội
etcd là một lựa chọn đã được kiểm chứng trong môi trường điều phối, với tài liệu mô hình đe dọa rõ ràng, chương trình kiểm thử độ bền công khai và lịch sử sự cố được viết ra thẳng thắn. [4][6][7] Giá trị lớn nhất của dự án nằm ở sự kỷ luật về ranh giới: mạng kín, mTLS, dữ liệu nhỏ và quan trọng.
Với khách sạn ven biển Đà Nẵng trong tình huống giả định, etcd chỉ hợp lý khi đội kỹ thuật tự xây hệ thống nhiều cơ sở và chấp nhận trách nhiệm vận hành một cụm đồng thuận. Nếu không, hãy để nhà cung cấp nền tảng lo phần này. Một hệ thống tri thức cá nhân như phamvanthu.com thì không cần etcd trực tiếp.
Bước tiếp theo hợp lý là thử nghiệm nhỏ theo kế hoạch ở trên, với tiêu chí dừng viết trước. Mọi nhận định trong bài này là kết quả đọc tài liệu ở một commit cố định, chưa có phép chạy thật nào.
Nguồn và phương pháp
Bài viết là nghiên cứu bàn giấy, không phải công trình khoa học đã qua bình duyệt. Người viết không cài đặt, chạy, đo hay triển khai etcd. Dự án được chọn từ kho lưu trữ GitHub Trending do cộng đồng lưu giữ; lần ghi nhận đầu tiên là ngày 2026-01-21 ở danh sách Go, vị trí thứ 8. [8] Kho này chỉ gồm các danh sách Python, Go, JavaScript và Swift, thiếu ngày 2026-09-03 và 2026-10-12, và không phải bảng xếp hạng top 100 chính thức.
Phiên bản được ghim là commit f061acd0902d489041448cdd19d71a345d27b9f5, ngày 2026-10-08, kiểm tra ngày 2026-10-12. Các tệp đã đọc gồm README, LICENSE, .github/SECURITY.md, THREAT_MODEL.md, Documentation/contributor-guide/roadmap.md, tests/robustness/README.md và báo cáo sau sự cố v3.5. [1][2][3][4][5][6][7]
Các tuyên bố kỹ thuật được gắn số tham chiếu; phần phân tích, khuyến nghị và tình huống Việt Nam là đề xuất của người viết.