Cloudflare ra mắt Workers Cache: Tăng tốc ứng dụng với bộ nhớ đệm ngay tại điểm truy cập

2026-07-06

17 phút đọc

Hôm nay, chúng tôi ra mắt Workers Cache: một bộ nhớ đệm phân tầng (tiered cache) nằm phía trước Worker của bạn, được cấu hình chỉ bằng một dòng trong Wrangler và sử dụng chính các tiêu đề Cache-Control mà bạn đã quen thuộc.

Khi Workers Cache được kích hoạt, mọi yêu cầu có thể lưu vào bộ nhớ đệm gửi đến Worker của bạn sẽ chạm vào bộ nhớ đệm của Cloudflare trước. Nếu có phản hồi mới trong bộ nhớ đệm, Cloudflare sẽ trả về trực tiếp — Worker của bạn không cần chạy và bạn không phải trả phí CPU cho yêu cầu đó. Nếu không tìm thấy (miss), Worker của bạn sẽ chạy, và nếu phản hồi đó có thể lưu vào bộ nhớ đệm, Cloudflare sẽ lưu trữ nó cho yêu cầu tiếp theo. Yêu cầu kế tiếp từ bất kỳ đâu trên thế giới đều có thể được phục vụ trực tiếp từ bộ nhớ đệm.

Toàn bộ quá trình chỉ nằm trong một khối cấu hình:

Sau đó, bạn kiểm soát việc lưu vào bộ nhớ đệm theo cách mà HTTP luôn hướng tới — bằng cách thiết lập các tiêu đề (headers) trên phản hồi của bạn:

Và khi nội dung thay đổi, Worker của bạn sẽ tự xóa bộ nhớ đệm của chính nó:

Đó là toàn bộ API. Không có vùng (zone) nào để cấu hình, không có công cụ quy tắc (rules engine) nào để thiết lập, không có bộ nhớ đệm riêng biệt nào để cung cấp và không có sản phẩm thứ hai nào để đăng nhập. Mã nguồn của Worker chính là giao diện cấu hình, và bộ nhớ đệm sẽ theo sát Worker bất kể nó chạy ở đâu — trên một tên miền tùy chỉnh, trên workers.dev, phía sau một service binding, trong bản xem trước (preview), hay trong một tenant của Workers for Platforms. Một Worker, một bộ nhớ đệm, cấu hình một lần duy nhất.

Đó là bề nổi. Còn rất nhiều thứ bên dưới: bộ nhớ đệm phân tầng trên toàn bộ mạng lưới của chúng tôi, hỗ trợ đầy đủ cho stale-while-revalidate để các phản hồi cũ không bao giờ chặn người dùng, thương lượng nội dung (content negotiation) thông qua Vary, khóa bộ nhớ đệm an toàn cho đa người dùng (multi-tenant) thông qua ctx.props, xóa bộ nhớ đệm theo lập trình bằng thẻ hoặc tiền tố đường dẫn, và — phần mà chúng tôi cho là bước đột phá lớn nhất — một bộ nhớ đệm nằm trước mọi điểm truy cập (entrypoint) của Worker, không chỉ điểm truy cập công khai, với khả năng kiểm soát từng điểm truy cập xem cái nào được lưu bộ nhớ đệm và cái nào không. Điểm cuối cùng này có nghĩa là bạn có thể tích hợp bộ nhớ đệm trực tiếp vào cấu trúc ứng dụng của mình: một chuỗi các điểm truy cập với các giai đoạn bộ nhớ đệm được chèn vào bất cứ nơi nào bạn muốn, được cấu hình bởi mã nguồn ở cả hai phía. Chúng tôi sẽ hướng dẫn chi tiết tất cả những điều này dưới đây.

Workers Cache hiện đã có sẵn cho mọi Worker trên bất kỳ gói dịch vụ nào, được kích hoạt trong Wrangler.

Đây là API bộ nhớ đệm mà chúng tôi luôn mong muốn Workers sở hữu. Dưới đây là lý do tại sao chúng tôi mất nhiều thời gian đến vậy, những gì có thể thực hiện được nhờ nó và những gì sắp tới.

Tại sao các ứng dụng render phía máy chủ (server-rendered) cần một bộ nhớ đệm phía trước

Khi chúng tôi giới thiệu Workers vào năm 2017, ý tưởng chính là bạn có thể chạy mã trên mạng lưới của Cloudflare để chuyển đổi các yêu cầu trên đường đến origin của bạn. Worker nằm phía trước bộ nhớ đệm và origin:

Đây là mô hình phù hợp cho các trường hợp sử dụng mà chúng tôi nhắm đến. Nếu bạn muốn thêm tiêu đề vào mọi yêu cầu, viết lại URL, thực hiện phân tách A/B hoặc lọc lưu lượng truy cập trước khi nó đến origin, việc đặt Worker phía trước bộ nhớ đệm và origin mang lại cho bạn toàn quyền kiểm soát những gì được lưu và không được lưu. Khách hàng đã xây dựng được những thứ tuyệt vời với nó.

Nhưng thế giới đã thay đổi. Workers không còn là thứ bạn gắn thêm vào một origin mà đã trở thành chính origin đó. Các framework như Astro, TanStack Start, Next.js, Remix và SvelteKit đều cung cấp Cloudflare adapter để xây dựng ứng dụng của bạn dưới dạng một Worker. Không có origin nào phía sau chúng cả. Worker chính là máy chủ.

Khi Worker là origin, kiến trúc ban đầu không có gì để lưu vào bộ nhớ đệm. Mọi yêu cầu đều chạy mã của bạn, ngay cả khi phản hồi giống hệt từng byte với phản hồi bạn đã trả về một giây trước đó. Runtime của Workers đủ nhanh để xử lý việc này — nó thường xuyên xử lý hàng chục triệu yêu cầu mỗi giây mà không gặp khó khăn gì — nhưng "đủ nhanh để render mọi yêu cầu" vẫn khiến bạn tốn độ trễ trên mỗi lần tải trang và tốn thời gian CPU trên mỗi lần gọi. Và đối với một ứng dụng render phía máy chủ, mỗi lần tải trang, theo định nghĩa, đều là một lần render.

Workers Cache thay đổi hoàn toàn kiến trúc đó. Bộ nhớ đệm của Cloudflare giờ đây nằm phía trước Worker:

Khi có cache hit, Worker của bạn hoàn toàn không chạy. Cloudflare trả về phản hồi đã lưu và hóa đơn CPU của bạn vẫn bằng không. Khi có cache miss, Worker của bạn chạy một lần, điền vào bộ nhớ đệm, và yêu cầu tiếp theo — từ bất kỳ đâu — sẽ được phục vụ từ bộ nhớ đệm mà không cần gọi mã của bạn.

Đây là mảnh ghép còn thiếu cho việc render phía máy chủ trên Workers. Trước đây, bạn phải chọn giữa hai lựa chọn không mấy hài lòng:

Render trước mọi thứ tại thời điểm build ("static site generation"). Tải trang nhanh, nhưng mỗi thay đổi đều yêu cầu build và deploy lại toàn bộ. Đối với một trang tài liệu có vài nghìn trang, mất khoảng 5–10 phút. Đối với một trang thương mại điện tử lớn, tình hình còn tệ hơn — và quá trình build chạy mỗi khi bạn thay đổi bất cứ thứ gì.

Render mọi trang trên mỗi yêu cầu. Nội dung luôn cập nhật, nhưng mỗi lần tải trang đều phải trả chi phí render và mỗi khách truy cập đều phải chịu độ trễ.

Workers Cache mang đến cho bạn lựa chọn thứ ba: render phía máy chủ theo yêu cầu (on demand), lưu phản hồi đã render vào bộ nhớ đệm, và làm mới nó theo thời gian tồn tại (TTL) mà bạn chọn. Yêu cầu đầu tiên đến một trang mới vẫn sẽ render. Mọi yêu cầu tiếp theo, cho đến khi bộ nhớ đệm hết hạn, đều được phục vụ như thể trang đó là tĩnh. Khi bộ nhớ đệm hết hạn, yêu cầu tiếp theo sẽ kích hoạt việc render lại — và với stale-while-revalidate, ngay cả yêu cầu đó cũng không cần phải chờ đợi.

Bạn có được tốc độ của một trang web tĩnh mà không cần thời gian build, và sự tươi mới của render phía máy chủ mà không tốn chi phí. Không cần các cơ chế đặc thù của framework như Incremental Static Regeneration. Chỉ đơn giản là bộ nhớ đệm HTTP, hoạt động đúng như thiết kế, nằm phía trước mã nguồn được thiết kế để làm origin.

stale-while-revalidate là yếu tố tạo nên cảm giác tức thì

Chỉ thị stale-while-revalidate báo cho Cloudflare biết rằng khi một phản hồi trong bộ nhớ đệm hết hạn, nó được phép phục vụ bản sao cũ (stale) ngay lập tức trong khi làm mới phản hồi đó ở chế độ nền. Cloudflare đã hỗ trợ đầy đủ stale-while-revalidate từ đầu năm nay, và đây chính là chỉ thị biến việc "chúng tôi lưu bộ nhớ đệm cho Worker của bạn" thành "trang web của Worker của bạn cho cảm giác như trang tĩnh".

Nếu không có nó, yêu cầu đầu tiên sau khi một mục trong bộ nhớ đệm hết hạn phải đợi Worker render lại trang từ đầu. Người dùng sẽ thấy độ trễ đó. Với nó, yêu cầu đầu tiên sau khi hết hạn sẽ nhận được trang cũ ngay lập tức (với tiêu đề Cf-Cache-Status: UPDATING), và Worker sẽ chạy ở chế độ nền để làm đầy lại bộ nhớ đệm. Mọi người dùng, bao gồm cả người đã kích hoạt việc làm mới, đều nhận được phản hồi với tốc độ của bộ nhớ đệm.

Trong thực tế, nó trông như thế này:

Mô hình tư duy giúp bạn nắm bắt điều này:

Cửa sổ tươi mới (max-age): Cloudflare phục vụ phản hồi đã lưu. Worker của bạn không chạy.

Cửa sổ cũ (stale-while-revalidate): Cloudflare phục vụ phản hồi đã lưu. Worker của bạn chạy ở chế độ nền để làm mới nó. Không người dùng nào phải chờ đợi.

Ngoài cả hai cửa sổ: Cloudflare chạy Worker của bạn để tạo phản hồi mới, và người dùng phải chờ đợi lần render đó.

Bạn là người chọn các cửa sổ này. Đối với một danh mục sản phẩm cập nhật vài phút một lần, max-age=300, stale-while-revalidate=3600 có nghĩa là khách truy cập gần như không bao giờ phải chờ đợi, và Worker của bạn vẫn chạy đủ thường xuyên để giữ nội dung luôn mới. Đối với một kho lưu trữ blog hầu như không bao giờ thay đổi, max-age=86400, stale-while-revalidate=2592000 có nghĩa là Worker của bạn chỉ chạy mỗi ngày một lần cho mỗi trang.

Yêu cầu đầu tiên đến một trang hoàn toàn mới là yêu cầu duy nhất phải trả toàn bộ chi phí render. Sau đó, trang web hoạt động như một đầu ra tĩnh đối với khách truy cập, trong khi Worker của bạn vẫn kiểm soát cách trang được tạo ra.

Một URL, nhiều biểu diễn: Vary hoạt động

Các ứng dụng thực tế hiếm khi trả về cùng một byte cho mọi client. Cùng một trang sản phẩm có thể là HTML cho trình duyệt và JSON cho API client. Cùng một hình ảnh có thể là WebP cho các client hỗ trợ và JPEG cho các client không hỗ trợ. Cùng một trang chủ có thể hiển thị bằng tiếng Anh, tiếng Pháp hoặc tiếng Nhật tùy thuộc vào người dùng.

Thực hiện việc này mà không có bộ nhớ đệm thì rất dễ — Worker của bạn chỉ cần đọc tiêu đề yêu cầu và trả về đúng thứ cần thiết. Thực hiện với bộ nhớ đệm mới là nơi mọi thứ thường trở nên phức tạp. Hầu hết các bộ nhớ đệm đều đưa ra hai lựa chọn tồi: không lưu gì cả trên các URL có nhiều biểu diễn, hoặc lưu một biểu diễn và phục vụ nó cho tất cả mọi người.

Workers Cache hỗ trợ tiêu đề HTTP Vary tiêu chuẩn, đây là cách đúng đắn để giải quyết vấn đề này. Khi Worker của bạn trả về một phản hồi với Vary: Accept-Encoding (hoặc Accept, hoặc Accept-Language, hoặc bất kỳ tiêu đề yêu cầu nào khác), Cloudflare sẽ lưu trữ một biến thể bộ nhớ đệm riêng biệt cho từng tổ hợp các tiêu đề đó — và chỉ trả về biến thể có các giá trị lưu trữ khớp với yêu cầu gửi đến.

Một URL, hai biến thể bộ nhớ đệm. Một trình duyệt gửi Accept: image/webp,*/* sẽ nhận được WebP. Một trình duyệt gửi Accept: image/jpeg sẽ nhận được JPEG. Cả hai đều đến từ bộ nhớ đệm. Worker của bạn ghi cả hai biến thể trong yêu cầu đầu tiên đến mỗi loại, và sau đó không cần chạy lần nào nữa cho cả hai trường hợp đó.

Đây là tiêu chuẩn HTTP đã được kiểm chứng cho việc thương lượng nội dung, và Workers Cache triển khai nó theo cách mà RFC 9110 và RFC 9111 mô tả. Không có danh sách cho phép (allowlist) về việc bạn có thể Vary trên những tiêu đề nào. Bạn liệt kê bất cứ thứ gì bạn cần, và Cloudflare sẽ tạo khóa cho các biến thể dựa trên các giá trị nguyên văn. Tài liệu hướng dẫn sẽ đi sâu vào các trường hợp đặc biệt — cách kiểm soát sự bùng nổ biến thể bằng cách chuẩn hóa tiêu đề trong một Gateway Worker, tại sao việc xóa bộ nhớ đệm lại làm mất hiệu lực của tất cả các biến thể của một URL cùng lúc, và trường hợp duy nhất (Vary: *) sẽ vô hiệu hóa hoàn toàn bộ nhớ đệm.