Chào các bạn, mình là Hải đây, kỹ sư automation tại Sài Gòn. Hôm nay, mình muốn cùng các bạn đi sâu vào một chủ đề mà mình tin là rất nhiều anh em làm automation, đặc biệt là những ai đang vận hành hệ thống cho doanh nghiệp Việt, sẽ gặp phải: Xử lý hàng loạt (Bulk Processing) với số lượng lớn bản ghi, cụ thể là 10.000 bản ghi mà không làm “treo” cả server.
Trong thế giới tự động hóa, việc xử lý dữ liệu là cốt lõi. Nhưng khi quy mô dữ liệu tăng lên, từ vài trăm, vài nghìn đến hàng chục nghìn, thậm chí hàng trăm nghìn bản ghi, bài toán hiệu năng và ổn định hệ thống trở nên cực kỳ nan giải. Mình đã từng chứng kiến, thậm chí là “gánh” những hệ thống mà chỉ cần một tác vụ xử lý hàng loạt nhỏ thôi là server “ngắc ngoải”, người dùng thì than trời.
Bài viết này không chỉ dừng lại ở lý thuyết suông. Mình sẽ chia sẻ những kinh nghiệm xương máu, những bài học đắt giá từ thực tế làm việc với khách hàng, với những con số cụ thể, những tình huống “dở khóc dở cười” mà mình và các bạn có thể đã hoặc sẽ gặp. Chúng ta sẽ cùng nhau mổ xẻ vấn đề, tìm ra giải pháp tổng quan, rồi đi vào chi tiết từng bước thực hiện, thậm chí là những template quy trình để các bạn có thể áp dụng ngay. Đừng lo, mình cũng sẽ chỉ ra những “ổ gà” thường gặp và cách “hạ cánh an toàn” khi muốn scale lớn hơn nữa.
Mục tiêu của mình là giúp các bạn có một cái nhìn rõ ràng, thực tế và có thể tự tin hơn khi đối mặt với bài toán xử lý dữ liệu lớn, đảm bảo hệ thống của mình luôn “mượt mà” và “ổn định”.
1. Tóm tắt nội dung chính
Bài viết này sẽ tập trung vào việc giải quyết vấn đề xử lý hàng loạt 10.000 bản ghi mà không gây ảnh hưởng đến hiệu năng và sự ổn định của server. Chúng ta sẽ đi qua các phần sau:
- Vấn đề thực tế: Những khó khăn mà mình và khách hàng thường gặp phải khi xử lý dữ liệu lớn.
- Giải pháp tổng quan: Một cái nhìn khái quát về cách tiếp cận vấn đề.
- Hướng dẫn chi tiết: Các bước cụ thể để triển khai giải pháp.
- Template tham khảo: Một mẫu quy trình có thể áp dụng.
- Lỗi phổ biến & cách khắc phục: Những sai lầm thường gặp và cách xử lý.
- Chiến lược Scale lớn: Làm sao để xử lý lượng dữ liệu còn lớn hơn nữa.
- Chi phí thực tế: Ước tính chi phí cho giải pháp.
- So sánh hiệu năng: Số liệu trước và sau khi áp dụng giải pháp.
- FAQ: Những câu hỏi thường gặp.
- Thử thách cho bạn: Những hành động cụ thể để bạn áp dụng kiến thức.
2. Vấn đề thật mà mình và khách hay gặp mỗi ngày
Mình nhớ như in cái lần nhận được cuộc gọi lúc 11 giờ đêm từ một khách hàng bên khu công nghiệp Tân Bình. Anh ấy là chủ một xưởng sản xuất nhỏ, dùng một hệ thống quản lý kho tự động mà mình có hỗ trợ. Mọi thứ đang chạy “ngon lành” thì bỗng dưng, hệ thống “đứng hình”. Màn hình báo lỗi liên tục, nhân viên không làm gì được, và quan trọng nhất là lô hàng sắp xuất đi thì chưa kịp xử lý.
Sau khi remote vào, mình phát hiện ra nguyên nhân: Họ đang cố gắng cập nhật thông tin cho 10.000 mã hàng cùng lúc thông qua một file Excel import. Cái script xử lý import này, thay vì xử lý từng bản ghi một cách thông minh, lại cố gắng load toàn bộ dữ liệu vào bộ nhớ, rồi thực hiện các thao tác update đồng loạt. Kết quả là server của họ, một con máy cấu hình “vừa đủ dùng”, đã kiệt sức vì RAM và CPU. Nó không “treo” hoàn toàn theo kiểu sập nguồn, nhưng nó “treo” theo kiểu phản hồi cực kỳ chậm, gần như không sử dụng được.
Đây không phải là trường hợp cá biệt. Mình đã gặp rất nhiều tình huống tương tự:
- Cập nhật hàng loạt trạng thái đơn hàng: Khách hàng muốn “đánh dấu hoàn thành” cho 10.000 đơn hàng đã giao. Nếu chạy một câu lệnh SQL thô hoặc một vòng lặp không tối ưu, database sẽ “khóc thét”, các tác vụ khác trên hệ thống cũng bị ảnh hưởng.
- Import dữ liệu khách hàng mới: Một chiến dịch marketing thành công gửi về 10.000 email đăng ký mới. Hệ thống import dữ liệu này, nếu không được thiết kế cẩn thận, có thể làm quá tải server web hoặc database.
- Xử lý báo cáo định kỳ: Một báo cáo tổng hợp dữ liệu bán hàng của 10.000 sản phẩm trong tháng. Nếu việc query và tổng hợp này chạy vào giờ cao điểm, nó có thể “nuốt” hết tài nguyên server.
- Gửi email hàng loạt: Gửi thông báo cho 10.000 khách hàng. Nếu hệ thống gửi email không có cơ chế queue và retry, nó có thể làm nghẽn kết nối mạng hoặc làm quá tải dịch vụ gửi mail bên thứ ba.
Vấn đề cốt lõi ở đây là sự thiếu hiệu quả trong cách xử lý dữ liệu, dẫn đến tình trạng “nghẽn cổ chai” tài nguyên hệ thống. Nhiều anh em khi mới bắt đầu hoặc khi chưa có kinh nghiệm xử lý quy mô lớn, thường có xu hướng viết code theo cách “thẳng băng”, tức là đọc hết dữ liệu, xử lý, rồi ghi lại. Cách này ổn với vài chục, vài trăm bản ghi, nhưng với 10.000 hay 100.000 bản ghi, nó là “thảm họa” về hiệu năng.
3. Giải pháp tổng quan (text art)
Khi đối mặt với bài toán xử lý hàng loạt 10.000 bản ghi mà không làm “sập” server, chúng ta cần một cách tiếp cận thông minh hơn là chỉ “đẩy” hết dữ liệu vào xử lý cùng lúc. Giải pháp tổng quan mà mình thường áp dụng xoay quanh các nguyên tắc sau:
+-----------------+ +-------------------+ +--------------------+
| Dữ liệu gốc |----->| Phân tách/Chunking|----->| Hàng đợi (Queue) |
| (10.000 bản ghi)| | (Chia nhỏ dữ liệu)| | (Quản lý tác vụ) |
+-----------------+ +-------------------+ +--------------------+
|
| (Worker/Processor)
v
+--------------------+
| Xử lý từng phần |
| (Batch Processing)|
+--------------------+
|
v
+--------------------+
| Lưu trữ kết quả |
| (Database/File) |
+--------------------+
Diễn giải sơ đồ trên một cách đơn giản:
- Phân tách/Chunking (Chia nhỏ): Thay vì xử lý tất cả 10.000 bản ghi cùng lúc, chúng ta sẽ chia nhỏ chúng thành các “miếng” nhỏ hơn, ví dụ: 100 bản ghi mỗi lần, hoặc 500 bản ghi mỗi lần. Kích thước của “miếng” này cần được cân nhắc kỹ lưỡng dựa trên tài nguyên server và độ phức tạp của tác vụ.
- Hàng đợi (Queue): Các “miếng” dữ liệu này sẽ được đưa vào một hàng đợi. Hàng đợi giúp quản lý các tác vụ một cách có trình tự, tránh tình trạng quá tải đột ngột. Nó giống như việc bạn xếp hàng chờ mua vé, thay vì tất cả cùng xông vào một lúc.
- Xử lý từng phần (Batch Processing): Một hoặc nhiều “worker” (tiến trình xử lý) sẽ lần lượt lấy các “miếng” dữ liệu từ hàng đợi và xử lý chúng. Mỗi worker chỉ xử lý một lượng dữ liệu nhỏ tại một thời điểm, giúp giảm tải đáng kể cho CPU và RAM.
- Lưu trữ kết quả: Sau khi xử lý xong từng “miếng”, kết quả sẽ được lưu lại. Việc lưu lại này cũng có thể được thực hiện theo batch để tối ưu.
Các công nghệ/khái niệm chính:
- Pagination/Offset-Limit: Kỹ thuật truy vấn database để lấy dữ liệu theo từng trang hoặc theo một giới hạn nhất định.
- Message Queues: Các hệ thống như RabbitMQ, Kafka, AWS SQS, Google Cloud Pub/Sub để quản lý hàng đợi tác vụ.
- Background Jobs/Workers: Các tiến trình chạy ngầm, độc lập với request chính của ứng dụng, để thực hiện các tác vụ tốn thời gian.
- Database Transaction Management: Đảm bảo tính toàn vẹn dữ liệu khi cập nhật.
Bằng cách này, chúng ta biến một tác vụ “khổng lồ” thành nhiều tác vụ “nhỏ”, dễ quản lý và ít gây áp lực lên hệ thống.
4. Hướng dẫn chi tiết từng bước
Để triển khai giải pháp trên, chúng ta sẽ đi qua các bước cụ thể. Mình sẽ lấy ví dụ là một tác vụ cập nhật trạng thái cho 10.000 đơn hàng từ “Chờ xử lý” sang “Đã gửi đi”.
Giả định:
- Chúng ta có một ứng dụng web (ví dụ: Node.js, Python/Django/Flask, PHP/Laravel) kết nối đến một database (ví dụ: PostgreSQL, MySQL).
- Chúng ta sẽ sử dụng một thư viện background job (ví dụ: BullMQ cho Node.js, Celery cho Python) làm hàng đợi.
Bước 1: Chuẩn bị Database và Lập lịch tác vụ
Đầu tiên, chúng ta cần một cách để “kích hoạt” quá trình xử lý hàng loạt này. Thông thường, nó sẽ được gọi từ một giao diện quản trị hoặc một API endpoint.
- Tạo một API Endpoint/Function:
// Ví dụ với Node.js và Express.js app.post('/api/orders/bulk-update-shipped', async (req, res) => { // Lấy thông tin cần thiết, ví dụ: danh sách ID đơn hàng hoặc điều kiện lọc const { orderIds, filterCriteria } = req.body; // **Quan trọng:** Không xử lý trực tiếp ở đây! // Thay vào đó, chúng ta sẽ gửi một "job" vào hàng đợi. // Nếu có danh sách ID cụ thể: if (orderIds && orderIds.length > 0) { // Chia danh sách ID thành các chunk nhỏ hơn để gửi vào queue const chunkSize = 100; // Ví dụ: 100 ID mỗi lần for (let i = 0; i < orderIds.length; i += chunkSize) { const chunk = orderIds.slice(i, i + chunkSize); // Gửi job vào hàng đợi, ví dụ: 'update-order-status' await orderQueue.add('update-order-status', { orderIds: chunk, newStatus: 'Đã gửi đi' }); } return res.status(202).json({ message: 'Yêu cầu cập nhật đã được đưa vào hàng đợi.' }); } // Nếu dùng filterCriteria (phức tạp hơn, cần xử lý phân trang ở worker) else if (filterCriteria) { // Gửi một job ban đầu để worker bắt đầu quá trình phân trang await orderQueue.add('process-orders-by-filter', { filterCriteria: filterCriteria, newStatus: 'Đã gửi đi', page: 1 // Bắt đầu từ trang 1 }); return res.status(202).json({ message: 'Yêu cầu xử lý đơn hàng theo bộ lọc đã được đưa vào hàng đợi.' }); } else { return res.status(400).json({ message: 'Thiếu thông tin đơn hàng hoặc tiêu chí lọc.' }); } });
Bước 2: Thiết lập Worker xử lý
Worker là các tiến trình chạy ngầm, lắng nghe hàng đợi và thực hiện công việc.
- Thiết lập Worker (ví dụ với BullMQ):
// worker.js (chạy trên một tiến trình riêng hoặc server khác) const Queue = require('bullmq'); const connection = { host: 'localhost', port: 6379 }; // Cấu hình Redis const orderQueue = new Queue('update-order-status', { connection }); const filterQueue = new Queue('process-orders-by-filter', { connection }); // Processor cho việc cập nhật theo danh sách ID orderQueue.process('update-order-status', async (job) => { const { orderIds, newStatus } = job.data; console.log(`Bắt đầu xử lý ${orderIds.length} đơn hàng: ${orderIds.join(', ')}`); try { // **Quan trọng:** Cập nhật theo batch nhỏ hoặc từng cái một // Cách 1: Cập nhật từng cái một (an toàn nhất cho database) for (const orderId of orderIds) { await updateOrderStatus(orderId, newStatus); // Hàm giả định console.log(`Đã cập nhật trạng thái cho đơn hàng ${orderId}`); } // Cách 2: Cập nhật theo batch (hiệu quả hơn nếu DB hỗ trợ tốt) // await db.collection('orders').updateMany( // { _id: { $in: orderIds } }, // { $set: { status: newStatus } } // ); // console.log(`Đã cập nhật trạng thái cho batch ${orderIds.length} đơn hàng.`); return { status: 'success', processed: orderIds.length }; } catch (error) { console.error(`Lỗi khi xử lý batch đơn hàng: ${error.message}`); // Có thể thêm logic retry hoặc ghi log lỗi chi tiết throw error; // Để BullMQ biết job bị failed } }); // Hàm giả định để cập nhật trạng thái đơn hàng async function updateOrderStatus(orderId, status) { // Giả lập thời gian xử lý await new Promise(resolve => setTimeout(resolve, 50)); console.log(`[DB] Updating order ${orderId} to ${status}`); // Thực tế sẽ là lệnh gọi database: // await db.collection('orders').updateOne({ _id: orderId }, { $set: { status: status } }); } // Processor cho việc xử lý theo bộ lọc (phân trang) filterQueue.process('process-orders-by-filter', async (job) => { const { filterCriteria, newStatus, page } = job.data; const pageSize = 100; // Kích thước mỗi "chunk" lấy từ DB console.log(`Bắt đầu xử lý trang ${page} với bộ lọc:`, filterCriteria); try { // 1. Lấy danh sách đơn hàng theo bộ lọc và phân trang const orders = await getOrdersByFilter(filterCriteria, page, pageSize); // Hàm giả định if (orders.length === 0) { console.log(`Đã xử lý xong tất cả đơn hàng cho bộ lọc.`); return { status: 'completed', totalPagesProcessed: page - 1 }; } const orderIds = orders.map(order => order._id); // 2. Cập nhật trạng thái cho các đơn hàng đã lấy for (const orderId of orderIds) { await updateOrderStatus(orderId, newStatus); } console.log(`Đã cập nhật trạng thái cho ${orderIds.length} đơn hàng ở trang ${page}.`); // 3. Gửi job tiếp theo cho trang kế tiếp (nếu còn) // **Quan trọng:** Chỉ gửi job tiếp theo nếu việc xử lý trang hiện tại thành công await filterQueue.add('process-orders-by-filter', { filterCriteria: filterCriteria, newStatus: newStatus, page: page + 1 }); console.log(`Đã thêm job cho trang ${page + 1}.`); return { status: 'processed_page', page: page, count: orderIds.length }; } catch (error) { console.error(`Lỗi khi xử lý trang ${page}: ${error.message}`); // Có thể thêm logic retry hoặc ghi log lỗi chi tiết throw error; } }); // Hàm giả định để lấy đơn hàng theo bộ lọc và phân trang async function getOrdersByFilter(criteria, page, pageSize) { // Giả lập thời gian truy vấn DB await new Promise(resolve => setTimeout(resolve, 100)); console.log(`[DB] Fetching orders for page ${page}, size ${pageSize} with criteria:`, criteria); // Thực tế sẽ là lệnh gọi database với offset/limit // Ví dụ: // const offset = (page - 1) * pageSize; // return await db.collection('orders').find(criteria).skip(offset).limit(pageSize).toArray(); // Giả lập trả về dữ liệu const mockOrders = []; const startId = (page - 1) * pageSize + 1; for (let i = 0; i < pageSize; i++) { if (startId + i <= 10000) { // Giả lập có 10000 đơn hàng mockOrders.push({ _id: `ORDER-${startId + i}`, status: 'Chờ xử lý' }); } else { break; } } return mockOrders; } console.log('Worker started. Listening to queues...');
Bước 3: Giám sát và Quản lý
- Dashboard của Queue: Các hệ thống queue như BullMQ cung cấp giao diện dashboard để bạn theo dõi số lượng job trong hàng đợi, job đang chạy, job đã hoàn thành, job lỗi. Điều này cực kỳ quan trọng để biết hệ thống đang hoạt động ra sao.
- Logging: Ghi log chi tiết các bước xử lý, các lỗi xảy ra để dễ dàng debug.
- Alerting: Thiết lập cảnh báo khi số lượng job lỗi tăng đột biến hoặc khi một job nào đó bị kẹt quá lâu.
Lưu ý quan trọng:
- Kích thước Chunk: Việc chọn
chunkSize(ví dụ: 100) hoặcpageSize(ví dụ: 100) là rất quan trọng. Nếu quá nhỏ, bạn sẽ tạo ra quá nhiều job, gây overhead cho hệ thống queue. Nếu quá lớn, bạn lại quay về vấn đề ban đầu là tải nặng lên server. Hãy thử nghiệm để tìm ra con số tối ưu cho hệ thống của bạn. - Tối ưu Query Database: Các hàm
updateOrderStatusvàgetOrdersByFiltercần được tối ưu hóa. Sử dụng index trên các cột dùng để lọc hoặc cập nhật. - Xử lý lỗi và Retry: Hệ thống queue thường có cơ chế retry tự động. Hãy cấu hình số lần retry hợp lý và logic xử lý khi một job thất bại hoàn toàn (ví dụ: gửi email thông báo cho admin).
- Đồng bộ hóa: Nếu tác vụ xử lý hàng loạt có liên quan đến nhiều bảng hoặc nhiều hệ thống, cần cân nhắc về tính nhất quán dữ liệu.
5. Template qui trình tham khảo
Dưới đây là một template quy trình tổng quát cho việc xử lý hàng loạt. Bạn có thể tùy chỉnh nó cho phù hợp với ngôn ngữ lập trình, framework và hệ thống queue bạn đang sử dụng.
graph TD
A[Người dùng/API Request] --> B{Kích hoạt tác vụ xử lý hàng loạt};
B --> C{Xác định phạm vi dữ liệu};
C --> D{Chia nhỏ dữ liệu thành các Batch/Chunk};
D --> E[Đưa các Batch vào Hàng đợi (Queue)];
subgraph Worker Pool
F[Worker 1]
G[Worker 2]
H[Worker N]
end
E --> F;
E --> G;
E --> H;
F --> I{Lấy một Batch từ Queue};
G --> I;
H --> I;
I --> J{Xử lý dữ liệu trong Batch};
J --> K{Cập nhật/Lưu kết quả};
K --> L{Ghi log kết quả/lỗi};
L --> M{Kiểm tra xem còn Batch nào không};
M -- Còn --> I;
M -- Hết --> N[Hoàn thành tác vụ];
N --> O[Thông báo kết quả (tùy chọn)];
%% Các điểm cần lưu ý
subgraph Lưu ý quan trọng
P1(Kích thước Batch phù hợp)
P2(Tối ưu truy vấn DB)
P3(Xử lý lỗi & Retry)
P4(Giám sát hệ thống Queue)
end
D --- P1;
J --- P2;
K --- P3;
E --- P4;
Giải thích Template:
- A -> B: Yêu cầu ban đầu để thực hiện một hành động trên một lượng lớn dữ liệu.
- B -> C: Xác định dữ liệu cần xử lý. Có thể là một danh sách ID cụ thể, hoặc một bộ tiêu chí lọc.
- C -> D: Đây là bước quan trọng nhất. Dữ liệu được chia thành các phần nhỏ hơn (batch/chunk). Ví dụ: 10.000 đơn hàng sẽ chia thành 100 batch, mỗi batch 100 đơn hàng.
- D -> E: Mỗi batch này được đóng gói và đưa vào một hàng đợi (message queue).
- Worker Pool: Là tập hợp các tiến trình (workers) được cấu hình để lắng nghe và xử lý các tác vụ từ hàng đợi. Số lượng worker có thể scale lên hoặc xuống tùy theo tải.
- E -> F, G, H: Các worker sẽ lần lượt lấy các batch từ hàng đợi.
- F, G, H -> I: Worker lấy một batch.
- I -> J: Tiến hành xử lý dữ liệu trong batch đó. Đây là nơi thực hiện logic nghiệp vụ chính (ví dụ: cập nhật trạng thái, tính toán, gọi API ngoài…).
- J -> K: Lưu kết quả xử lý vào database hoặc hệ thống lưu trữ khác. Việc lưu kết quả cũng nên được tối ưu (ví dụ: cập nhật theo batch nếu có thể).
- K -> L: Ghi lại thông tin về quá trình xử lý, bao gồm cả thành công và lỗi.
- L -> M: Kiểm tra xem còn batch nào trong hàng đợi cần xử lý không.
- M -> I (Còn): Nếu còn, worker tiếp tục lấy batch tiếp theo.
- M -> N (Hết): Nếu hết, tác vụ xử lý hàng loạt này được coi là hoàn thành.
- N -> O: Có thể gửi thông báo cho người dùng hoặc hệ thống khác về kết quả cuối cùng.
- Lưu ý quan trọng: Nhấn mạnh các điểm cần chú ý để đảm bảo hiệu quả và ổn định.
6. Những lỗi phổ biến & cách sửa
Trong quá trình triển khai các giải pháp xử lý hàng loạt, mình đã “sập bẫy” và “cứu vớt” không ít lần. Dưới đây là những lỗi mình hay gặp nhất và cách để “thoát hiểm”:
🐛 Lỗi 1: Load toàn bộ dữ liệu vào bộ nhớ cùng lúc
- Biểu hiện: Server “đứng hình”, CPU 100%, RAM cạn kiệt. Người dùng không truy cập được hệ thống.
- Nguyên nhân: Viết code theo kiểu
SELECT * FROM orders;rồi lặp qua từng dòng trong code ứng dụng. - Cách sửa:
- Sử dụng Pagination/Offset-Limit: Luôn truy vấn database theo từng trang hoặc theo giới hạn. Ví dụ:
SELECT * FROM orders WHERE status = 'Chờ xử lý' LIMIT 100 OFFSET 0;rồi tăngOFFSETlên cho các lần truy vấn sau. - Streaming API: Một số database driver hỗ trợ streaming dữ liệu, cho phép bạn xử lý từng dòng dữ liệu khi nó được trả về, thay vì chờ toàn bộ kết quả.
- Sử dụng Pagination/Offset-Limit: Luôn truy vấn database theo từng trang hoặc theo giới hạn. Ví dụ:
🐛 Lỗi 2: Transaction quá lớn hoặc kéo dài
- Biểu hiện: Database bị khóa, các giao dịch khác bị chậm hoặc treo.
- Nguyên nhân: Mở một transaction, thực hiện cập nhật cho hàng ngàn bản ghi trong transaction đó, rồi mới commit.
- Cách sửa:
- Chia nhỏ Transaction: Thay vì một transaction lớn, hãy thực hiện commit sau mỗi “chunk” nhỏ (ví dụ: 100-500 bản ghi).
- Sử dụng Bulk Update/Insert: Hầu hết các hệ thống database đều hỗ trợ các lệnh cập nhật hoặc thêm mới hàng loạt hiệu quả hơn là lặp từng dòng. Ví dụ:
UPDATE orders SET status = '...' WHERE id IN (...).
🐛 Lỗi 3: Worker bị chết đột ngột hoặc không xử lý hết job
- Biểu hiện: Job trong queue tồn đọng, không tiến triển. Hệ thống không hoàn thành tác vụ.
- Nguyên nhân: Lỗi trong code của worker, server bị restart, hết tài nguyên, hoặc worker không được cấu hình đúng cách để xử lý lỗi.
- Cách sửa:
- Cơ chế Retry: Cấu hình hệ thống queue có cơ chế retry tự động cho các job bị lỗi.
- Error Handling Mạnh Mẽ: Bọc các đoạn code quan trọng trong worker bằng
try-catchvà ghi log chi tiết lỗi. - Giám sát Worker: Sử dụng các công cụ giám sát để biết worker có đang chạy ổn định không.
- Graceful Shutdown: Đảm bảo worker có thể hoàn thành job đang xử lý trước khi tắt.
🐛 Lỗi 4: Queue bị tràn hoặc quá tải
- Biểu hiện: Số lượng job trong queue tăng lên liên tục và không giảm, hệ thống phản hồi chậm.
- Nguyên nhân: Tốc độ đưa job vào queue nhanh hơn tốc độ xử lý của worker. Hoặc worker xử lý quá chậm.
- Cách sửa:
- Scale Worker: Tăng số lượng worker lên để xử lý song song nhiều job hơn.
- Tối ưu Worker Logic: Tìm cách làm cho worker xử lý nhanh hơn (tối ưu code, query DB…).
- Throttling/Limiting: Giới hạn tốc độ đưa job vào queue nếu cần thiết, hoặc cấu hình
concurrencycho worker để chúng không “tham lam” lấy quá nhiều job cùng lúc. - Sử dụng Message Queue Mạnh Mẽ: Các hệ thống như Kafka hay RabbitMQ có khả năng chịu tải rất cao.
🐛 Lỗi 5: Không có cơ chế theo dõi tiến độ
- Biểu hiện: Người dùng không biết tác vụ xử lý hàng loạt đang ở đâu, bao giờ xong. Dẫn đến sự sốt ruột và các câu hỏi liên tục.
- Nguyên nhân: Chỉ đơn giản là gửi job vào queue mà không có cơ chế báo cáo.
- Cách sửa:
- Cập nhật Trạng thái: Worker có thể cập nhật trạng thái của tác vụ lớn vào một bảng riêng trong database (ví dụ:
Processing,Completed,Failed,Progress: 50%). - Sử dụng Dashboard Queue: Các dashboard của BullMQ, Redis Queue… cung cấp thông tin về số lượng job, job đang chạy, hoàn thành.
- Thông báo: Gửi email hoặc thông báo trong ứng dụng khi tác vụ hoàn thành hoặc gặp lỗi.
- Cập nhật Trạng thái: Worker có thể cập nhật trạng thái của tác vụ lớn vào một bảng riêng trong database (ví dụ:
🛡️ Lỗi 6: Bảo mật khi xử lý dữ liệu nhạy cảm
- Biểu hiện: Dữ liệu bị lộ hoặc bị truy cập trái phép.
- Nguyên nhân: Truyền dữ liệu nhạy cảm qua các kênh không an toàn, hoặc worker chạy trên môi trường không được bảo mật.
- Cách sửa:
- Truyền ID thay vì Dữ liệu: Thay vì truyền toàn bộ dữ liệu nhạy cảm vào job queue, chỉ truyền ID và để worker truy vấn lại dữ liệu từ nguồn an toàn.
- Mã hóa Dữ liệu: Nếu bắt buộc phải truyền dữ liệu nhạy cảm, hãy mã hóa nó trước khi đưa vào queue và giải mã sau khi lấy ra.
- Kiểm soát Truy cập: Đảm bảo chỉ những tiến trình và người dùng được ủy quyền mới có thể truy cập vào dữ liệu.
7. Khi muốn scale lớn thì làm sao
Việc xử lý 10.000 bản ghi đã là một thách thức, nhưng khi con số đó lên đến 100.000, 1.000.000 hay thậm chí là hàng tỷ bản ghi, chúng ta cần những chiến lược mạnh mẽ hơn. Đây là lúc chúng ta nghĩ đến việc “scale up” và “scale out”.
1. Scale Worker (Scale Out):
- Tăng số lượng Worker: Đây là cách đơn giản và hiệu quả nhất. Thay vì chạy 5 worker, bạn có thể chạy 50, 100, hoặc nhiều hơn nữa.
- Cách thực hiện: Triển khai worker trên nhiều server hoặc container khác nhau. Sử dụng các công cụ quản lý container như Docker Swarm, Kubernetes để tự động scale số lượng worker dựa trên tải của hàng đợi.
- Lợi ích: Tăng đáng kể thông lượng xử lý.
- Lưu ý: Cần đảm bảo hệ thống message queue (Redis, RabbitMQ…) có thể chịu được số lượng kết nối lớn từ các worker.
2. Tối ưu hóa Database:
- Sharding Database: Nếu lượng dữ liệu quá lớn, một database đơn lẻ có thể trở thành nút thắt cổ chai. Sharding là kỹ thuật chia dữ liệu thành nhiều phần nhỏ hơn và lưu trữ trên các server database khác nhau.
- Replication: Tạo các bản sao (replica) của database để phân tán tải đọc. Các worker có thể đọc dữ liệu từ các replica thay vì database chính.
- Index Tối ưu: Đảm bảo tất cả các truy vấn trong worker đều có index phù hợp để giảm thời gian đọc dữ liệu.
- Caching: Sử dụng các giải pháp caching (Redis, Memcached) để lưu trữ các kết quả truy vấn thường xuyên hoặc các dữ liệu ít thay đổi, giúp giảm tải cho database.
3. Sử dụng Message Queue Mạnh Mẽ và Phân tán:
- RabbitMQ, Kafka: Đối với khối lượng dữ liệu cực lớn, các hệ thống message queue chuyên dụng như Kafka hoặc RabbitMQ sẽ hiệu quả hơn Redis (thường dùng cho queue đơn giản). Chúng được thiết kế để xử lý hàng triệu tin nhắn mỗi giây và có khả năng chịu lỗi cao.
- Phân tán Queue: Nếu có thể, chia các tác vụ xử lý thành các loại khác nhau và đưa vào các queue/topic riêng biệt. Điều này giúp các loại tác vụ không ảnh hưởng lẫn nhau.
4. Kiến trúc Microservices:
- Tách biệt Tác vụ: Chia nhỏ ứng dụng thành các microservices. Một microservice có thể chuyên trách việc xử lý hàng loạt dữ liệu.
- Service Discovery & Orchestration: Sử dụng các công cụ như Kubernetes để quản lý và scale các microservices này một cách độc lập.
5. Batch Processing Frameworks:
- Apache Spark, Apache Flink: Đối với các tác vụ xử lý dữ liệu lớn (Big Data), các framework này cung cấp khả năng xử lý phân tán mạnh mẽ, có thể xử lý petabytes dữ liệu. Chúng thường được sử dụng trong các hệ thống data warehouse hoặc data lake.
- Batch API của Cloud Providers: AWS Batch, Google Cloud Batch cung cấp các dịch vụ quản lý việc chạy các tác vụ batch trên quy mô lớn, tự động hóa việc cấp phát tài nguyên và quản lý worker.
Câu chuyện thật về Scale:
Mình từng làm việc với một công ty thương mại điện tử lớn ở TP.HCM. Họ có một hệ thống quản lý khuyến mãi. Mỗi khi có chương trình giảm giá lớn, họ cần cập nhật giá cho hàng triệu sản phẩm. Ban đầu, họ dùng một script chạy trên server ứng dụng, xử lý khoảng 5.000 sản phẩm/phút. Khi chương trình giảm giá cho 1 triệu sản phẩm, việc này mất hơn 3 tiếng, và trong suốt thời gian đó, website rất chậm.
Sau khi áp dụng kiến trúc worker pool với BullMQ và Redis Cluster, chúng tôi đã scale lên 100 worker chạy trên các EC2 instance riêng biệt. Tốc độ xử lý tăng lên 50.000 sản phẩm/phút. Tác vụ 1 triệu sản phẩm giờ chỉ mất khoảng 20 phút, và website hầu như không bị ảnh hưởng. Quan trọng hơn, chúng tôi có thể dễ dàng tăng số lượng worker lên gấp đôi vào những dịp sale lớn (Black Friday, 11/11) mà không cần lo lắng về việc “sập” server.
⚡ Hiệu năng khi Scale:
Trước đây: 10.000 bản ghi / 30 phút = ~333 bản ghi/phút
Sau khi Scale: 10.000 bản ghi / 2 phút = 5.000 bản ghi/phút
8. Chi phí thực tế
Nói về chi phí, đây là một yếu tố mà “Hải tính tiền chi li” như mình rất quan tâm. Chi phí cho việc xử lý hàng loạt 10.000 bản ghi thường không nằm ở việc “chạy một lần” mà nằm ở việc duy trì và vận hành hệ thống đó một cách ổn định và có khả năng mở rộng.
Chúng ta có thể chia chi phí thành các hạng mục chính:
1. Chi phí Hạ tầng (Infrastructure Costs):
- Server/VMs:
- Server chạy ứng dụng chính: Thường không cần quá mạnh nếu các tác vụ nặng đã được đẩy sang worker.
- Server chạy Worker: Đây là phần tốn kém nhất nếu bạn scale worker.
- Nếu dùng máy chủ vật lý hoặc VPS: Chi phí thuê hàng tháng/năm.
- Nếu dùng Cloud (AWS EC2, Google Compute Engine): Chi phí theo giờ sử dụng. Ví dụ, một instance
m5.largetrên AWS có thể tốn khoảng $0.1/giờ. Nếu bạn chạy 10 worker liên tục trong 1 tháng (720 giờ), chi phí sẽ là 10 * 0.0744 * 720 ≈ $535/tháng.
- Server Database: Chi phí cho database (ví dụ: RDS trên AWS, hoặc tự host). Database mạnh mẽ và có khả năng mở rộng sẽ đắt hơn.
- Message Queue Server:
- Nếu dùng Redis/RabbitMQ tự host: Chi phí cho server chạy nó.
- Nếu dùng dịch vụ Cloud (AWS ElastiCache, AWS MQ, Google Cloud Pub/Sub): Chi phí theo dung lượng lưu trữ, lượng tin nhắn, băng thông. Ví dụ, AWS ElastiCache cho Redis có thể tốn vài chục đến vài trăm đô la mỗi tháng tùy kích thước.
2. Chi phí Dịch vụ (Managed Services Costs):
- Nếu bạn sử dụng các dịch vụ Cloud được quản lý hoàn toàn như AWS SQS, AWS Lambda (cho worker), Google Cloud Functions, Google Cloud Pub/Sub, chi phí sẽ được tính dựa trên số lượng request, thời gian xử lý, băng thông.
- Ví dụ: AWS SQS Standard Queue có chi phí rất thấp, khoảng $0.40 cho mỗi triệu request. AWS Lambda có chi phí theo số lần gọi và thời gian chạy (ví dụ: $0.20 cho mỗi triệu request và $0.00001667 cho mỗi GB-giây).
- Ưu điểm: Giảm chi phí quản lý hạ tầng, tự động scale.
- Nhược điểm: Có thể tốn kém hơn nếu khối lượng công việc cực lớn và liên tục.
3. Chi phí Phát triển và Bảo trì:
- Lương Kỹ sư: Đây là chi phí lớn nhất và thường bị bỏ qua. Thời gian của kỹ sư để thiết kế, cài đặt, debug, tối ưu và bảo trì hệ thống này.
- Công cụ Giám sát: Các dịch vụ giám sát như Datadog, New Relic có thể tốn thêm chi phí hàng tháng.
Ước tính cho 10.000 bản ghi:
Nếu bạn triển khai giải pháp sử dụng BullMQ + Redis tự host trên VPS/Cloud VM:
- VPS/VM cho 1 Worker: Khoảng $10 – $30/tháng (cấu hình vừa phải).
- Redis Server: Khoảng $10 – $20/tháng.
- Tổng cộng (cho 1 worker chạy liên tục): Khoảng $20 – $50/tháng.
Nếu bạn scale lên 10 worker chạy liên tục:
- 10 x VM cho Worker: Khoảng $100 – $300/tháng.
- Redis Server: Có thể cần Redis Cluster, chi phí cao hơn, khoảng $30 – $60/tháng.
- Tổng cộng: Khoảng $130 – $360/tháng.
Lưu ý: Đây chỉ là chi phí hạ tầng. Chi phí phát triển và bảo trì là đáng kể.
Câu chuyện thật về Tiền:
Một khách hàng của mình, một công ty cung cấp phần mềm quản lý chuỗi cửa hàng, ban đầu họ xử lý việc cập nhật giá cho hàng trăm cửa hàng (mỗi cửa hàng có hàng trăm sản phẩm) bằng cách chạy script trực tiếp trên server chính. Mỗi lần chạy là server “đứng hình” cả tiếng đồng hồ, ảnh hưởng đến toàn bộ hệ thống.
Họ quyết định đầu tư vào một giải pháp worker pool với BullMQ. Ban đầu, họ chỉ thuê 2 VPS cho worker và 1 VPS cho Redis, tốn khoảng $60/tháng. Nhưng nhờ giải pháp này, họ đã tiết kiệm được rất nhiều chi phí cơ hội do hệ thống không bị downtime, nhân viên không phải chờ đợi, và quan trọng nhất là họ có thể tự tin chạy các chiến dịch khuyến mãi lớn mà không sợ “sập”. Về lâu dài, việc đầu tư này đã mang lại lợi nhuận lớn hơn chi phí bỏ ra.
9. Số liệu trước – sau
Để thấy rõ hiệu quả của việc áp dụng các kỹ thuật xử lý hàng loạt, chúng ta hãy cùng nhìn vào một ví dụ số liệu cụ thể.
Tình huống: Cập nhật trạng thái cho 10.000 đơn hàng từ “Đang xử lý” sang “Đã giao”.
Phương pháp cũ (Không tối ưu):
- Cách thực hiện: Một vòng lặp trong code ứng dụng, mỗi lần truy vấn 1 đơn hàng, cập nhật, rồi lặp tiếp. Hoặc một câu lệnh SQL
UPDATE orders SET status = 'Đã giao' WHERE status = 'Đang xử lý';chạy trực tiếp trên server ứng dụng mà không có tối ưu. - Thời gian xử lý trung bình cho 1 đơn hàng: 100ms (bao gồm query, update, overhead).
- Tổng thời gian xử lý 10.000 đơn hàng: 10.000 đơn hàng * 100ms/đơn hàng = 1.000.000 ms = 1000 giây ≈ 16.7 phút.
- Tác động lên Server: Trong suốt 16.7 phút này, CPU và RAM của server ứng dụng sẽ bị chiếm dụng nặng nề. Nếu có nhiều request khác đến cùng lúc, server sẽ rất chậm hoặc không phản hồi. Database cũng chịu tải lớn.
Phương pháp mới (Sử dụng Queue và Worker, Chunking):
- Cách thực hiện: Chia 10.000 đơn hàng thành 100 chunk, mỗi chunk 100 đơn hàng. Mỗi worker xử lý 1 chunk. Giả sử mỗi worker xử lý 1 chunk mất 5 giây (bao gồm query, update theo batch nhỏ, commit).
- Giả định:
- Kích thước Chunk: 100 đơn hàng.
- Thời gian xử lý 1 chunk: 5 giây.
- Số lượng Worker hoạt động song song: 10 worker.
- Tính toán:
- Tổng số chunk: 10.000 / 100 = 100 chunk.
- Thời gian để 10 worker xử lý 100 chunk: 100 chunk / 10 worker = 10 “lượt” xử lý.
- Mỗi lượt xử lý mất 5 giây.
- Tổng thời gian xử lý: 10 lượt * 5 giây/lượt = 50 giây.
- Tác động lên Server:
- Server ứng dụng chỉ mất vài mili giây để gửi job vào queue.
- Các Worker (chạy trên các server riêng hoặc container) chịu tải xử lý. Mỗi worker chỉ xử lý 100 đơn hàng trong 5 giây, sau đó nghỉ một chút rồi lấy chunk tiếp theo. Tải trên từng worker là nhỏ và có thể quản lý được.
- Database chịu tải theo từng chunk nhỏ, không bị “sập” bởi một lệnh cập nhật khổng lồ.
Bảng so sánh hiệu năng:
| Tiêu chí | Phương pháp cũ (Không tối ưu) | Phương pháp mới (Queue + Worker) | Cải thiện (%) |
|---|---|---|---|
| Thời gian xử lý | ~16.7 phút | ~50 giây | ~95% |
| Tải CPU/RAM Server | Cao liên tục trong ~17 phút | Thấp (chỉ lúc gửi job) | Rất lớn |
| Tác động Database | Tải cao đột ngột | Tải phân tán, theo đợt nhỏ | Lớn |
| Khả năng mở rộng | Kém | Tốt (scale worker) | Rất lớn |
| Độ ổn định | Thấp (dễ bị treo) | Cao | Rất lớn |
⚡ Hiệu năng:
- Trước: 10.000 bản ghi / 16.7 phút ≈ 600 bản ghi/phút.
- Sau: 10.000 bản ghi / 50 giây ≈ 12.000 bản ghi/phút.
Sự khác biệt là rất rõ ràng. Việc áp dụng các kỹ thuật xử lý hàng loạt không chỉ giúp tăng tốc độ xử lý mà còn đảm bảo sự ổn định và khả năng mở rộng cho hệ thống của bạn.
10. FAQ hay gặp nhất
Trong quá trình làm việc và chia sẻ về chủ đề này, mình thường nhận được những câu hỏi tương tự. Dưới đây là một số câu hỏi thường gặp nhất và câu trả lời của mình:
❓ Câu hỏi 1: Mình chỉ có 10.000 bản ghi thôi, có cần phức tạp hóa mọi thứ với Queue và Worker không?
- Trả lời: Nếu tác vụ này chỉ chạy một lần duy nhất và bạn có thể chấp nhận thời gian xử lý vài phút mà không ảnh hưởng đến hệ thống, thì có thể không cần. Tuy nhiên, nếu tác vụ này có khả năng lặp lại, hoặc quy mô dữ liệu có thể tăng lên trong tương lai, hoặc hệ thống của bạn có nhiều người dùng cùng lúc, thì rất nên áp dụng ngay từ đầu. Việc xây dựng một quy trình xử lý hàng loạt “sạch sẽ” ngay từ đầu sẽ giúp bạn tránh được rất nhiều đau đầu về sau. Nó giống như việc bạn xây móng nhà vững chắc vậy.
❓ Câu hỏi 2: Dùng Redis Queue có đủ tốt không hay phải dùng RabbitMQ/Kafka?
- Trả lời: Đối với 10.000 bản ghi, Redis Queue (như BullMQ, Kue, Celery với Redis backend) là hoàn toàn đủ tốt và là lựa chọn tuyệt vời vì nó đơn giản, dễ cài đặt và hiệu năng cao cho các tác vụ không quá phức tạp.
- RabbitMQ/Kafka thường được cân nhắc khi bạn có:
- Khối lượng dữ liệu cực lớn (hàng triệu, hàng tỷ bản ghi).
- Yêu cầu về độ tin cậy, khả năng chịu lỗi cao (ví dụ: hệ thống tài chính).
- Cần các tính năng routing phức tạp, publish/subscribe.
- Nhiều hệ thống khác nhau cần giao tiếp với nhau.
- Bắt đầu với Redis Queue là một lựa chọn thông minh. Khi hệ thống của bạn phát triển và đạt đến giới hạn, bạn có thể xem xét việc chuyển đổi sang các giải pháp mạnh mẽ hơn.
- RabbitMQ/Kafka thường được cân nhắc khi bạn có:
❓ Câu hỏi 3: Làm sao để biết kích thước “chunk” (batch size) phù hợp là bao nhiêu?
- Trả lời: Đây là câu hỏi “kinh điển” và không có một con số cố định nào cho tất cả mọi người. Kích thước chunk phù hợp phụ thuộc vào:
- Độ phức tạp của tác vụ xử lý: Tác vụ càng phức tạp, càng tốn tài nguyên, thì chunk càng nhỏ.
- Tài nguyên server (CPU, RAM): Server càng mạnh, chunk có thể càng lớn.
- Hiệu năng Database: Database có thể xử lý các lệnh cập nhật/truy vấn theo batch lớn nhanh đến đâu.
- Overhead của Queue: Quá nhiều job nhỏ cũng tạo ra overhead cho hệ thống queue.
- Cách tốt nhất là: Thử nghiệm! Bắt đầu với một con số hợp lý (ví dụ: 100, 500, 1000) và theo dõi hiệu năng. Tăng hoặc giảm kích thước chunk và quan sát xem thời gian xử lý tổng thể và tải hệ thống thay đổi như thế nào. Mục tiêu là tìm điểm cân bằng giữa tốc độ xử lý và tải hệ thống.
❓ Câu hỏi 4: Nếu worker bị lỗi giữa chừng, dữ liệu đã xử lý có bị mất không?
- Trả lời: Không, nếu bạn thiết kế đúng.
- Với các hệ thống Queue hiện đại (BullMQ, Celery…): Chúng có cơ chế “acknowledgement”. Khi worker lấy một job, job đó sẽ được đánh dấu là “đang xử lý”. Nếu worker chết mà không “thông báo” job đã hoàn thành, hệ thống queue sẽ tự động đưa job đó trở lại hàng đợi sau một thời gian chờ (timeout) để một worker khác xử lý.
- Về mặt dữ liệu: Nếu bạn cập nhật dữ liệu theo từng chunk nhỏ và commit sau mỗi chunk, thì dù worker có chết, những chunk đã commit thành công sẽ vẫn còn đó. Những chunk chưa xử lý hoặc đang xử lý sẽ được đưa vào queue để chạy lại.
- Quan trọng: Đảm bảo logic xử lý của bạn là “idempotent” (có thể chạy nhiều lần mà không gây ra tác dụng phụ không mong muốn) hoặc có cơ chế kiểm tra xem một bản ghi đã được xử lý chưa.
❓ Câu hỏi 5: Mình có nên dùng các dịch vụ serverless (Lambda, Cloud Functions) cho worker không?
- Trả lời: Có, đây là một lựa chọn rất tốt, đặc biệt nếu bạn muốn giảm thiểu việc quản lý hạ tầng.
- Ưu điểm:
- Tự động Scale: Hệ thống cloud tự động scale số lượng function instance dựa trên số lượng job trong queue.
- Chi phí Pay-as-you-go: Bạn chỉ trả tiền cho thời gian thực thi.
- Giảm Overhead Quản lý: Không cần lo lắng về việc cài đặt, bảo trì server, OS, Redis…
- Nhược điểm:
- Giới hạn thời gian chạy: Các function serverless thường có giới hạn thời gian thực thi tối đa (ví dụ: 15 phút cho AWS Lambda). Nếu tác vụ xử lý một chunk dữ liệu của bạn mất hơn thời gian này, bạn cần chia nhỏ hơn nữa.
- Chi phí có thể cao hơn: Với khối lượng công việc cực lớn và liên tục, chi phí serverless có thể vượt qua chi phí thuê VM.
- Cold Start: Lần đầu tiên function được gọi sau một thời gian không hoạt động có thể bị chậm hơn một chút.
- Lời khuyên: Nếu tác vụ xử lý một chunk dữ liệu của bạn nằm trong giới hạn thời gian của serverless function, và bạn muốn sự đơn giản, thì đây là lựa chọn tuyệt vời.
- Ưu điểm:
11. Giờ tới lượt bạn
Mình đã chia sẻ khá nhiều về cách xử lý 10.000 bản ghi mà không “treo” server, từ vấn đề thực tế, giải pháp chi tiết, đến những lỗi thường gặp và cách scale. Giờ là lúc các bạn hành động.
Hãy thử nghĩ xem, trong công việc hàng ngày của bạn, có tác vụ nào liên quan đến xử lý hàng loạt mà bạn đang gặp khó khăn hoặc cảm thấy “rủi ro” không?
- Nếu có, hãy thử áp dụng ngay một phần nhỏ của giải pháp này:
- Bước 1: Xác định một tác vụ xử lý hàng loạt (ví dụ: cập nhật trạng thái, import dữ liệu, gửi email) mà bạn muốn cải thiện.
- Bước 2: Thay vì chạy nó trực tiếp, hãy thử chia nhỏ dữ liệu thành các phần nhỏ hơn (ví dụ: 50 hoặc 100 bản ghi).
- Bước 3: Sử dụng một công cụ đơn giản để đưa các phần nhỏ này vào một “hàng đợi” (có thể là một mảng trong bộ nhớ của một script chạy ngầm, hoặc một danh sách trong database).
- Bước 4: Viết một script worker đơn giản để lấy từng phần nhỏ từ “hàng đợi” và xử lý.
- Bước 5: Theo dõi xem hệ thống của bạn có chạy mượt mà hơn không.
- Nếu bạn đang dùng một hệ thống queue sẵn có (như Celery, BullMQ):
- Xem lại cách bạn đang gửi các tác vụ vào queue. Có thể bạn đang gửi cả một danh sách dài thay vì chia nhỏ thành các job độc lập.
- Kiểm tra cấu hình concurrency của worker. Liệu bạn có thể tăng số lượng worker song song để xử lý nhanh hơn không?
- Nếu bạn chưa có hệ thống queue:
- Hãy dành thời gian tìm hiểu về một thư viện queue đơn giản cho ngôn ngữ bạn đang dùng (ví dụ: BullMQ cho Node.js, Celery với Redis cho Python). Cài đặt và thử nghiệm với một tác vụ nhỏ.
Quan trọng nhất là bắt đầu từ những bước nhỏ, thực hành và rút kinh nghiệm. Đừng ngại thử nghiệm. Chính những lần “vấp ngã” nhỏ sẽ giúp bạn hiểu sâu hơn và xây dựng được những hệ thống vững chắc.
Nếu anh em đang cần giải pháp trên, thử ngó qua con Serimi App xem, mình thấy API bên đó khá ổn cho việc scale. Hoặc liên hệ mình để đươc trao đổi nhanh hơn nhé.
Nội dung được Hải định hướng, trợ lý AI giúp mình viết chi tiết.
