FastAPI vs Celery: Khi nào nên dùng BackgroundTasks và khi nào cần Task Queue phân tán?

Khi xây dựng API bất đồng bộ với FastAPI, hầu như lập trình viên backend nào cũng gặp bài toán quen thuộc: API cần xử lý một tác vụ tốn thời gian mà không được bắt client phải chờ đợi HTTP response.

Đó có thể là gửi email kích hoạt tài khoản, đồng bộ dữ liệu thanh toán từ Stripe webhook, xuất báo cáo tài chính PDF nặng 50 trang, hoặc tạo vector embedding để lưu vào Qdrant.

Trong tài liệu chính thức của FastAPI, tác giả giới thiệu một tính năng tích hợp sẵn cực kỳ hấp dẫn:

from fastapi import BackgroundTasks, FastAPI

app = FastAPI()

def send_welcome_email(email: str):
    # Logic gửi email...
    pass

@app.post("/register")
async def register(email: str, background_tasks: BackgroundTasks):
    background_tasks.add_task(send_welcome_email, email)
    return {"status": "accepted", "message": "Email kích hoạt đang được gửi"}

Trông như một phép màu: Không cần cài thêm Redis hay RabbitMQ, không cần chạy Celery worker process riêng, không tốn thêm tài nguyên máy chủ. Chỉ một dòng gọi hàm là client nhận ngay phản hồi 202 Accepted trong khi tác vụ chạy ngầm.

Cho đến khi hệ thống của bạn lên môi trường Production thực tế.

Pod Kubernetes bắt đầu bị Out-Of-Memory (OOM) kill liên tục. Toàn bộ worker Uvicorn bị đóng băng (freeze) 3-5 giây mỗi lần có ai đó xuất báo cáo. Mỗi lần CI/CD deploy phiên bản mới, hàng trăm task đang chạy bị ngắt đột ngột mà không để lại bất kỳ dấu vết lỗi nào. Và khi dịch vụ gửi mail đối tác trả về lỗi tạm thời 502 Bad Gateway, email bị mất vĩnh viễn vì không hề có cơ chế thử lại (retry).

Bài viết này sẽ mổ xẻ chuyên sâu kiến trúc FastAPI BackgroundTasks và Celery, đo đạc benchmark thực tế khi chịu tải 10,000 task, chỉ ra 4 "cái bẫy" chết người trên production và đưa ra framework ra quyết định chuẩn xác cho năm 2026.

Kiến Trúc: In-Process vs Hàng Đợi Phân Tán (Distributed)

Sự khác biệt cốt lõi giữa BackgroundTasks và Celery không nằm ở cú pháp thư viện, mà nằm ở ranh giới cô lập tài nguyên (resource isolation) và tính bền vững của dữ liệu (durability).

1. FastAPI BackgroundTasks: Chạy In-Process Trong Cùng Worker

FastAPI kế thừa trực tiếp cơ chế BackgroundTasks từ Starlette. Khi bạn gọi background_tasks.add_task(), Starlette chỉ đơn giản lưu hàm và tham số vào một list Python trong bộ nhớ RAM gắn liền với đối tượng Response:

# Cốt lõi cơ chế nội bộ của Starlette
class BackgroundTasks:
    def __init__(self, tasks=None):
        self.tasks = list(tasks) if tasks else []

    def add_task(self, func, *args, **kwargs):
        self.tasks.append(BackgroundTask(func, *args, **kwargs))

    async def __call__(self):
        for task in self.tasks:
            await task()

Khi route handler hoàn thành, Starlette truyền header và body HTTP về client qua socket ASGI. Ngay sau khi socket đóng, Starlette duyệt qua self.tasks và chạy lần lượt từng hàm ngay trong chính tiến trình Uvicorn worker đó.

• Không có tính bền vững (Persistence): Task chỉ sống tạm thời trong RAM của worker tiến trình web.
• Dùng chung tài nguyên: Tác vụ ngầm cạnh tranh trực tiếp CPU và RAM với các HTTP request mới đang gửi đến.
• Gắn chặt vòng đời: Nếu worker bị crash, pod bị restart hoặc container khởi động lại, toàn bộ task đang chờ và đang chạy sẽ biến mất ngay lập tức.

2. Celery: Hệ Thống Hàng Đợi Phân Tán Độc Lập

Celery tách rời hoàn toàn tiến trình nhận request (Producer) và tiến trình thực thi tác vụ (Consumer) thông qua một Message Broker bền vững (Redis hoặc RabbitMQ):

1. Producer (FastAPI): Đóng gói tham số dưới dạng JSON message và đẩy vào hàng đợi Redis (LPUSH tasks.send_email). Request HTTP trả về client trong vòng 2-3ms.
2. Broker (Redis / RabbitMQ): Lưu trữ message an toàn trên RAM và disk. Dù API server có sập, message vẫn được bảo toàn nguyên vẹn trong hàng đợi.
3. Consumer (Celery Workers): Các worker độc lập chạy trên máy chủ hoặc container riêng biệt liên tục lấy message về xử lý, tự động retry với exponential backoff nếu gặp lỗi, và lưu kết quả vào backend.

Bảng So Sánh Kiến Trúc Chi Tiết

4 Cái Bẫy "Chết Người" Khi Dùng BackgroundTasks Trên Production

Bẫy 1: Làm Nghẽn Event Loop (Event Loop Starvation)

Một lỗi rất phổ biến khi code Python bất đồng bộ là gọi hàm chặn (blocking synchronous call) bên trong một hàm async def:

# CẢNH BÁO BẪY: Hàm khai báo là async def nhưng bên trong gọi sync I/O
async def sync_user_data(user_id: str):
    import requests # Thư viện HTTP đồng bộ gây nghẽn!
    response = requests.get(f"https://api.thirdparty.com/users/{user_id}")

Vì hàm được khai báo với async def, FastAPI sẽ chạy nó trực tiếp trên main asyncio event loop. Khi requests.get() chờ phản hồi mạng mất 2 giây, toàn bộ worker Uvicorn sẽ bị đứng hình hoàn toàn trong suốt 2 giây đó.

Trong khoảng thời gian đó, worker không thể nhận kết nối TCP mới, không thể xử lý SSL handshake, và thậm chí không thể phản hồi probe GET /healthz của Kubernetes. Sau vài lần health check thất bại, Kubernetes sẽ coi pod đã chết và gửi lệnh tiêu diệt pod.

Bẫy 2: Mất Toàn Bộ Task Khi Rolling Deploy

Trong các hệ thống hiện đại sử dụng Kubernetes hoặc Docker Swarm, việc deploy phiên bản mới diễn ra liên tục hàng ngày.

Khi container cũ bị thay thế:

1. Kubernetes gửi tín hiệu SIGTERM đến container và chờ một khoảng thời gian ngắn (grace period).
2. Uvicorn lập tức ngừng nhận kết nối mới và tiến hành tắt process.
3. Những task đang chạy dở sẽ bị ngắt ngang xương. Những task đang nằm chờ trong mảng self.tasks của Starlette chưa kịp chạy sẽ bị xóa sạch vĩnh viễn khỏi bộ nhớ RAM.
4. Client nhận được thông báo "Đã tiếp nhận yêu cầu", nhưng thực tế dữ liệu không bao giờ được xử lý!

Ngược lại, với Celery, task nằm an toàn trên Redis. Khi worker nhận tín hiệu SIGTERM, nếu cấu hình task_acks_late = True và task_reject_on_worker_lost = True, task chưa hoàn tất sẽ được tự động trả lại hàng đợi để worker khác nhận lại.

Bẫy 3: Phình Bộ Nhớ (Memory Leak) Không Kiểm Soát

FastAPI BackgroundTasks không hề có cơ chế giới hạn hàng đợi (backpressure). Nếu hệ thống nhận đột biến 3,000 request/phút mà mỗi task mất 500ms CPU để xử lý, tốc độ sinh task sẽ vượt xa năng lực xử lý của máy chủ.

Mảng self.tasks trong RAM phình to liên tục. Bộ nhớ tiến trình tăng vọt từ 80MB lên 1GB trong vài phút, dẫn đến Linux kernel kích hoạt OOM Killer để hạ gục tiến trình web ngay lập tức.

Với Celery:

• Broker đóng vai trò đệm giảm xóc (buffer), lưu trữ hàng triệu message mà không ảnh hưởng đến API server.
• Web server luôn giữ mức RAM ổn định (< 100MB).
• Worker có thể tự động co giãn (autoscaling) theo chiều dài hàng đợi nhờ KEDA trên Kubernetes.

Triển Khai Thực Tế: Code So Sánh

# main.py
import time
from fastapi import FastAPI, BackgroundTasks, status
from pydantic import BaseModel, EmailStr

app = FastAPI(title="Email Gateway")

class WelcomeEmailRequest(BaseModel):
    user_id: int
    email: EmailStr

def send_welcome_email(email: str, user_id: int):
    # Tác vụ đồng bộ nhẹ, chỉ chấp nhận được cho email không quan trọng
    time.sleep(1.0)
    print(f"Đã gửi email chào mừng tới user {user_id}: {email}")

@app.post("/users/welcome", status_code=status.HTTP_202_ACCEPTED)
def register_user(payload: WelcomeEmailRequest, tasks: BackgroundTasks):
    tasks.add_task(send_welcome_email, payload.email, payload.user_id)
    return {"status": "queued", "user_id": payload.user_id}

# tasks.py
import os
import time
from celery import Celery

REDIS_URL = os.getenv("REDIS_URL", "redis://localhost:6379/0")

celery_app = Celery("worker", broker=REDIS_URL, backend=REDIS_URL)

celery_app.conf.update(
    task_serializer="json",
    accept_content=["json"],
    result_serializer="json",
    timezone="UTC",
    # Cấu hình tin cậy cốt lõi:
    task_acks_late=True,                 # Chỉ ack sau khi hoàn thành task
    task_reject_on_worker_lost=True,     # Re-queue nếu worker sập giữa chừng
    worker_prefetch_multiplier=1,        # Chia đều task cho các worker
    worker_max_tasks_per_child=200       # Restart worker sau 200 task để tránh leak RAM
)

@celery_app.task(
    bind=True,
    autoretry_for=(Exception,),
    retry_backoff=True,
    retry_kwargs={"max_retries": 5}
)
def process_report_task(self, user_id: int, report_type: str):
    time.sleep(3.0) # Giả lập tính toán nặng
    return {"user_id": user_id, "status": "done", "file_url": "https://s3.locionic.com/report.pdf"}

# api.py
from fastapi import FastAPI, status
from pydantic import BaseModel
from tasks import process_report_task

app = FastAPI(title="Report Processing Gateway")

class ReportRequest(BaseModel):
    user_id: int
    report_type: str

@app.post("/reports/generate", status_code=status.HTTP_202_ACCEPTED)
def generate_report(payload: ReportRequest):
    # .delay() đẩy message vào Redis cực nhanh (chỉ 2-3ms)
    task = process_report_task.delay(payload.user_id, payload.report_type)
    return {"task_id": task.id, "status": "PENDING"}

@app.get("/reports/status/{task_id}")
def check_status(task_id: str):
    res = process_report_task.AsyncResult(task_id)
    return {"task_id": task_id, "status": res.state, "result": res.result if res.ready() else None}

Kết Quả Benchmark 10,000 Tác Vụ Đột Biến

Thử nghiệm giả lập 10,000 request đẩy vào hệ thống trong vòng 60 giây trên máy chủ 2 vCPU, 2GB RAM:

Khi Nào Nên Dùng Cái Gì?

Kết Luận

FastAPI BackgroundTasks là một công cụ tuyệt vời cho các tác vụ phụ trợ nhẹ nhàng, không quan trọng, diễn ra tại chỗ trong cùng máy chủ.

Nhưng ngay khi tác vụ của bạn liên quan đến nghiệp vụ sống còn của doanh nghiệp (tiền bạc, thanh toán, email khách hàng, tính toán dữ liệu nặng), việc đưa Celery + Message Broker vào dự án không phải là sự phức tạp hóa quá mức, mà là một yêu cầu bắt buộc về mặt kiến trúc hệ thống. Tách biệt tầng Web phục vụ HTTP và tầng Worker xử lý nền chính là chìa khóa để hệ thống backend luôn mượt mà, ổn định và sẵn sàng mở rộng quy mô.

You Might Also Like

• FastAPI vs Litestar (2026): Performance, Benchmarks & When to Switch
• Optimizing Python FastAPI for High-Concurrency
• Profiling Async Python Memory Leaks in Production
• FastAPI Docker Multistage Builds: Cut Your Image Size by 70%