标签：#asyncprocessing

Async processing qua message queue: vì sao đẩy việc nặng ra khỏi request path, và cái giá phải trả bằng eventual consistency Async processing là mô hình tách một request thành hai giai đoạn: request handler nhận việc, xác nhận với client, rồi giao phần xử lý thật cho một worker chạy ngoài request path — thường qua một message queue (RabbitMQ, AWS SQS, Kafka, Redis Streams, hoặc queue trên nền Redis như BullMQ/Sidekiq). Lý do dev gặp nó trong việc thật rất cụ thể: một endpoint gọi payment provider mất 3s, gửi email confirm mất 1s, resize ảnh mất 5s — nếu làm tuần tự trong request, p99 latency của endpoint là tổng các con số đó, và một downstream chậm hoặc chết đủ để làm timeout hết thread pool của app server. Đẩy vào queue thì request trả về trong vài chục ms; nhưng đổi lại, cái "xong" mà client thấy không còn nghĩa là việc đã thực sự hoàn thành. Cơ chế hoạt động Ba thành phần: producer (thường là API server) đóng gói việc thành message rồi publish vào broker; broker (RabbitMQ/SQS/Kafka…) giữ message trong queue có persistence tuỳ cấu hình; consumer/worker poll hoặc được push message, xử lý, rồi ack để broker biết xoá. Nếu worker chết trước khi ack, broker redeliver — đây là gốc của semantic at-least-once : mỗi message được giao ít nhất một lần, có thể nhiều lần. Exactly-once trong hệ phân tán chỉ đạt được ở lớp application bằng cách consumer viết idempotent, không phải bằng cấu hình broker. Ví dụ với RabbitMQ + Node ( amqplib ): // producer — trong HTTP handler const ch = await conn . createConfirmChannel () await ch . assertQueue ( ' image.resize ' , { durable : true }) app . post ( ' /upload ' , async ( req , res ) => { const jobId = crypto . randomUUID () const payload = Buffer . from ( JSON . stringify ({ jobId , s3Key : req . body . key })) await ch . sendToQueue ( ' image.resize ' , payload , { persistent : true , // ghi xuống disk, sống sót broker restart messageId : jobId , // để consumer dedupe contentType : ' application/json ' , }) // đợi broker confirm đ