Cloudflare Queues: Tác Vụ Nền Tại Biên

Cloudflare Queues giải quyết đúng vấn đề mà mọi ứng dụng serverless sớm muộn cũng gặp: một yêu cầu đi tới và kích hoạt phần việc mà người dùng lẽ ra không phải ngồi chờ. Gửi email xác nhận, đổi kích thước ảnh vừa tải lên, đồng bộ bản ghi sang một dịch vụ bên thứ ba. Trên máy chủ truyền thống, bạn giao việc đó cho một tiến trình nền. Trên Workers thì không có tiến trình nào để giao cả.

Những cách chữa cháy quen thuộc tệ hơn vẻ ngoài của chúng. Làm việc đó ngay trong luồng chính buộc người dùng phải chờ một nhà cung cấp email. Bắn một yêu cầu sang Worker khác rồi không chờ kết quả sẽ làm mất tác vụ mỗi khi lần gọi ban đầu kết thúc trước. Không cách nào trong hai cách đó sống sót qua một sự cố của nhà cung cấp.

Điều một hàng đợi thực sự mang lại: tính bền vững và khả năng thử lại, chứ không phải tốc độ. Producer ghi một thông điệp rồi trả về ngay, một Worker consumer riêng biệt nhận lấy nó, và nếu consumer thất bại thì thông điệp quay lại hàng đợi thay vì biến mất. Toàn bộ giá trị nằm ở đó. Nếu tác vụ nền của bạn không chịu được việc bị chạy lại, hàng đợi sẽ không cứu được bạn.

Các mảnh ghép khớp với nhau thế nào

Một hàng đợi có hai đầu, và cả hai đầu đều là Workers.

Producer là bất kỳ Worker nào có binding tới hàng đợi. Nó gọi send kèm phần thân thông điệp, và lời gọi đó trả về ngay khi thông điệp đã được lưu bền vững. Yêu cầu của người dùng kết thúc mà không phải chờ phần việc kia.

Consumer là một Worker có handler cho hàng đợi. Cloudflare gọi nó với một lô thông điệp, và handler xác nhận từng thông điệp mà nó xử lý thành công. Bất cứ thứ gì không được xác nhận đều sẽ được gửi lại.

Hành vi gửi lại chính là phần đáng để bạn thiết kế xoay quanh. Một thông điệp có thể tới nhiều hơn một lần, nghĩa là consumer của bạn phải có tính idempotent. Trừ tiền một thẻ trong consumer mà không có khóa idempotency là cách chắc chắn để rồi phải hoàn tiền cho khách. Gửi trùng một email thì khó chịu, thu tiền hai lần thì đã là sự cố hỗ trợ khách hàng.

Một dead letter queue hứng lấy những thông điệp hỏng lặp đi lặp lại. Không có nó, một thông điệp hỏng vĩnh viễn sẽ bị thử lại đến khi hết lượt rồi biến mất. Có nó, thông điệp rơi vào một nơi bạn có thể mở ra xem. Hãy cấu hình trước khi bạn cần đến.

Một thao tác thực sự tốn bao nhiêu

Mô hình giá đủ khác thường để làm nhiều đội vấp phải, bởi vì bạn không bị tính tiền theo từng thông điệp.

Một thao tác được tính cho mỗi 64 KB dữ liệu được ghi, đọc hoặc xóa. Một thông điệp dưới 64 KB được giao bình thường tốn ba thao tác: một lần ghi, một lần đọc, một lần xóa. Một thông điệp 127 KB tốn hai thao tác cho mỗi hành động, tức là sáu thao tác cho cùng một lần giao duy nhất.

Việc thử lại làm thay đổi phép tính. Mỗi lần gửi lại là thêm một lần đọc, và một lần ghi vào dead letter queue là thêm một lần ghi. Một consumer thất bại năm lần trên cùng một thông điệp trước khi thành công sẽ tốn nhiều hơn ba thao tác rất nhiều, và đó là lý do nên sửa một consumer chập chờn thay vì nâng số lần thử lại của nó.

Hãy tính trên chính lưu lượng của bạn trước khi kết luận rằng nó rẻ. Một triệu thông điệp mỗi tháng, mỗi thông điệp ba thao tác, là ba triệu thao tác, vượt hạn mức của gói trả phí và tốn khoảng tám mươi xu Anh. Con số đó đúng là rẻ. Mười triệu thông điệp mỗi ngày lại là một câu chuyện khác.

Những giới hạn quyết định mức phù hợp

Theo tài liệu về giới hạn của Queues từ Cloudflare, đã kiểm chứng vào tháng 8 năm 2026.

Hai trong số đó quan trọng hơn phần còn lại. Trần 128 KB cho mỗi thông điệp nghĩa là bạn không đưa tệp vào hàng đợi. Bạn đưa một con trỏ vào hàng đợi và đưa tệp vào R2, vốn dĩ cũng là hình thức đúng đắn. Mức tồn đọng 25 GB là thứ bảo vệ bạn khỏi thảm họa âm thầm: nếu consumer hỏng vào một ngày thứ Sáu và không ai để ý, hàng đợi sẽ đầy rồi từ chối thông điệp mới bằng một lỗi lưu trữ, thay vì lặng lẽ vứt bỏ chúng.

Thông lượng 5.000 thông điệp mỗi giây là hào phóng, nhưng tính trên mỗi hàng đợi. Một hàng đợi bị dồn tải là nút thắt cổ chai mà bạn có thể loại bỏ ngay từ khâu thiết kế bằng cách chia tải ra nhiều hàng đợi.

Khi nào Cloudflare Queues là câu trả lời sai

Khi phần việc thực sự đồng bộ. Nếu người dùng cần thấy kết quả trên màn hình, đưa nó vào hàng đợi chỉ thêm một vòng đi về và một bài toán polling. Hãy làm ngay tại chỗ và làm cho nhanh.

Khi bạn cần xử lý theo thứ tự và đúng một lần. Queues cho bạn kiểu giao ít nhất một lần. Bất cứ thứ gì đòi hỏi thứ tự nghiêm ngặt hoặc ngữ nghĩa đúng một lần đều cần mức điều phối mà hàng đợi không cung cấp, và trên Cloudflare điều đó thường có nghĩa là một Durable Object.

Khi đó là tác vụ theo lịch chứ không phải tác vụ được kích hoạt. Việc dọn dẹp hằng đêm không cần hàng đợi. Một cron trigger gọi thẳng một Worker thì đơn giản hơn và ít bộ phận chuyển động hơn.

Khi phần việc kéo dài quá 15 phút. Một consumer chạy vượt giới hạn thời gian sẽ bị dừng giữa chừng. Những quy trình dài nhiều bước cần đến Cloudflare Workflows, thứ được xây dựng cho việc thực thi bền vững xuyên qua nhiều bước, chứ không phải một consumer cố giữ trạng thái suốt mười lăm phút.

Hướng dẫn của chúng tôi về xây dựng API serverless với Cloudflare Workers mô tả đường đi của yêu cầu vốn thường sinh ra các tác vụ này, còn bài Cloudflare Workers so với AWS Lambda nói về sự khác biệt của mô hình thực thi so với mẫu SQS cộng Lambda mà phần lớn các đội mang theo.

Bắt đầu từ đâu

Hãy chọn đúng một phần việc trong handler xử lý yêu cầu mà người dùng không cần chờ, và chỉ chuyển phần đó đi. Cho nó một dead letter queue ngay từ ngày đầu, làm cho consumer có tính idempotent, và theo dõi chỉ số tồn đọng thay vì mặc định rằng nó đang trống.

Mecanik thiết kế và rà soát kiến trúc tại biên thông qua đội phát triển phần mềm của chúng tôi, bao gồm cả phần có người đặt câu hỏi liệu tác vụ đó có thực sự cần hàng đợi hay không. Phần lớn hệ thống chỉ cần một hoặc hai, chứ không phải mỗi tính năng một cái.

Bài viết liên quan: Cloudflare Hyperdrive: Postgres từ biên , Cách xây dựng ứng dụng web năm 2026: hướng dẫn UK , Cloudflare D1: xây dựng cơ sở dữ liệu SQL serverless tại biên và Cloudflare Workers AI: chạy mô hình AI tại biên năm 2026 .

Câu hỏi thường gặp

Cloudflare Queues có giá bao nhiêu? Gói Workers Free bao gồm 10.000 thao tác mỗi ngày và gói trả phí bao gồm một triệu thao tác mỗi tháng, thao tác vượt mức có giá 0,40 USD mỗi triệu và không có phí egress. Một thao tác được tính cho mỗi 64 KB được ghi, đọc hoặc xóa, nên một thông điệp bình thường dưới 64 KB tốn tổng cộng ba thao tác: một lần ghi, một lần đọc và một lần xóa.

Cái gì được tính là một thao tác trong Cloudflare Queues? Mỗi 64 KB dữ liệu được ghi, đọc hoặc xóa. Thông điệp nhỏ hơn 64 KB tốn một thao tác cho mỗi hành động, trong khi thông điệp 127 KB tốn hai thao tác cho mỗi hành động. Mỗi lần thử lại thêm một lần đọc, và một lần ghi vào dead letter queue thêm một lần ghi, nên một consumer chập chờn tốn hơn hẳn ba thao tác cơ bản cho mỗi thông điệp.

Kích thước thông điệp tối đa trong Cloudflare Queues là bao nhiêu? 128 KB cho mỗi thông điệp, còn gửi theo lô bị giới hạn ở 100 thông điệp hoặc tổng cộng 256 KB. Vì cái trần đó, bạn lưu phần dữ liệu trong R2 hoặc một kho đối tượng khác và chỉ đặt một con trỏ vào hàng đợi, vốn là thiết kế tốt hơn bất kể giới hạn.

Cloudflare Queues có bảo đảm giao đúng một lần không? Không. Việc giao là ít nhất một lần, nên một thông điệp có thể tới nhiều lần và consumer của bạn phải có tính idempotent. Thu một khoản thanh toán hoặc phát hành một khoản tín dụng bên trong consumer mà không có khóa idempotency thì sớm muộn cũng bị nhân đôi. Thứ tự nghiêm ngặt hoặc ngữ nghĩa đúng một lần cần đến Durable Object thay thế.

Khi nào tôi không nên dùng Cloudflare Queues? Khi người dùng đang chờ kết quả, khi bạn cần thứ tự nghiêm ngặt hoặc xử lý đúng một lần, khi tác vụ chạy theo lịch chứ không do sự kiện kích hoạt và một cron trigger là đủ, hoặc khi phần việc chạy lâu hơn giới hạn 15 phút của consumer. Trường hợp cuối cùng chính là lý do Cloudflare Workflows tồn tại.