Giải mã kiến trúc D1: Cách Cloudflare mở rộng quy mô lên hàng triệu cơ sở dữ liệu

Kiến trúc cơ sở dữ liệu truyền thống thường dựa trên một hoặc hai cụm database lớn đi kèm với giải pháp kết nối pooling. Tuy nhiên, sự bùng nổ của các nền tảng phát triển hỗ trợ bởi AI và xu hướng “vibe coding” đang thay đổi mô hình này, thúc đẩy nhu cầu về hàng triệu cơ sở dữ liệu nhỏ – mỗi người dùng hoặc mỗi môi trường preview sẽ sở hữu một database riêng.

D1, cơ sở dữ liệu serverless dựa trên SQLite của Cloudflare, được thiết kế để đáp ứng chính xác nhu cầu này. Thách thức đặt ra là làm thế nào để mở rộng quy mô control plane cho hàng triệu database mà không tạo ra các nút thắt cổ chai làm chậm truy vấn. Cloudflare đã thực hiện nhiều thay đổi kiến trúc quan trọng để giải quyết bài toán này.

Nguyên tắc kỹ thuật cốt lõi

Để xây dựng hệ thống có khả năng mở rộng, Cloudflare áp dụng các nguyên tắc sau:

• Thiết kế hướng tới sự thất bại và tính lũy đẳng (idempotency): Hệ thống phải có khả năng tự sửa lỗi và tiếp tục vận hành.
• Tránh các thành phần tập trung: Không đặt các thành phần đơn vùng (single-region) vào “hot path” của các thao tác data plane.
• Sử dụng Workers KV: Lưu trữ metadata định tuyến phân tán toàn cầu để giảm thiểu truy vấn vào database trung tâm.
• Tận dụng Hyperdrive: Sử dụng Hyperdrive để kết nối với Postgres trung tâm, tối ưu hóa pooling và caching.
• Tính nhất quán cuối cùng (Eventual consistency): Sử dụng hàng đợi giữa các thành phần không yêu cầu tính nhất quán mạnh để tăng độ tin cậy.

Kiến trúc cấp cao

Mỗi database D1 được hỗ trợ bởi một Durable Object (DO) SQLite. Khi người dùng thực hiện thao tác, yêu cầu sẽ đi qua Edge API Worker. Đối với các thao tác CRUD (tạo, xóa, liệt kê), hệ thống sử dụng Hyperdrive để truy vấn cụm Postgres trung tâm. Đối với các truy vấn SQL, yêu cầu được chuyển tiếp đến D1 Eyeball Worker, đóng vai trò proxy xử lý các logic như quan sát (observability), thử lại tự động (automatic retries) và xử lý lỗi.

Quy trình tạo database nhanh chóng

Khi người dùng tạo database, quy trình bao gồm: kiểm tra giới hạn tài khoản, tạo UUID, khởi tạo Durable Object và lưu trữ metadata vào Postgres cũng như Workers KV. Để tối ưu hóa, Cloudflare chuyển tiếp việc thực thi đến trung tâm dữ liệu gần người dùng nhất, đảm bảo Durable Object được đặt tại vị trí tối ưu.

Một điểm quan trọng là quy trình này được thiết kế để tự phục hồi. Nếu việc ghi vào Postgres thất bại, hệ thống sẽ thử lại với các ID mới. Việc khởi tạo Durable Object luôn được thực hiện trước khi lưu mapping vào Postgres để đảm bảo tính toàn vẹn.

Cơ chế Heartbeat để tự sửa lỗi

Các Durable Object của D1 định kỳ gửi heartbeat (mỗi 30 giây) tới control plane để cập nhật trạng thái database. Cơ chế này cho phép các Durable Object tự điều chỉnh theo “nguồn sự thật” (source of truth) là Postgres. Nếu một Durable Object không còn hợp lệ (ví dụ: do quá trình tạo bị lỗi trước đó), nó sẽ nhận được phản hồi từ control plane và tự hủy, giúp hệ thống luôn sạch sẽ và nhất quán mà không cần can thiệp thủ công.

Nguồn tham khảo: Cloudflare Blog