Mở rộng quy mô pipeline tích hợp lên 8.000 event/giây mà không phá vỡ tính đúng đắn dữ liệu

Trong hạ tầng tích hợp dữ liệu doanh nghiệp, việc tăng thông lượng (throughput) thường đi kèm với nguy cơ âm thầm làm hỏng dữ liệu. Bài viết này là một bản tường thuật sản xuất chi tiết về cách một pipeline đã được nâng từ 500 lên 8.000 event mỗi giây, đồng thời giữ vững hai cam kết về tính đúng đắn mà tốc độ không bao giờ được phép vi phạm.

---

Bối cảnh: bài toán không hề đơn giản

Công việc được mô tả là tích hợp dữ liệu doanh nghiệp – kết nối dữ liệu từ hơn 20 hệ thống kinh doanh riêng biệt (đơn hàng, tồn kho, tài chính, logistics, hồ sơ khách hàng) cùng một đống kênh FTP batch kế thừa mà không ai muốn động vào. Mỗi ngày pipeline phải xử lý vài triệu event, và vào dịp cuối tháng hoặc các đợt khuyến mãi lớn, con số này tăng lên gấp nhiều lần.

Nghe thì có vẻ đơn giản: hệ thống A gọi API của hệ thống B. Nhưng vấn đề thực sự không nằm ở việc kết nối, mà là giữ cho dữ liệu đúng sau khi đã kết nối. Trong số hơn 20 hệ thống đó, có hệ thống mới nói chuyện bằng REST, có hệ thống thuê ngoài từ 10 năm trước chỉ hiểu SOAP, và ít nhất một hệ thống chỉ biết thả file qua FTP. Khi có sự cố, toàn bộ trách nhiệm đổ lên vai lớp trung gian – chính là pipeline này.

Tầng đáy không được phép vi phạm

Trước khi nói về tốc độ, tác giả nhấn mạnh hai cam kết bất biến mà mọi thay đổi về thông lượng đều phải tôn trọng:

Thứ nhất, một phiên bản cũ hơn của trạng thái thực thể không bao giờ được phép ghi đè lên phiên bản mới hơn. Trong một pipeline phân tán, cùng một bản cập nhật logic có thể đến nhiều lần và lệch thứ tự – do truyền lại mạng, phát lại từ hàng đợi, hoặc consumer khởi động lại giữa chừng. Giải pháp là mỗi thực thể mang một số phiên bản (version) do hệ thống nguồn sở hữu, và thao tác ghi sẽ từ chối mọi bản ghi cũ:

public void upsertWithVersionCheck(EntitySync sync) {
    int updated = jdbcTemplate.update(
        "UPDATE entity_store SET data = ?, version = ?, updated_at = NOW() " +
        "WHERE entity_id = ? AND entity_type = ? AND version < ?",
        sync.getData(), sync.getVersion(), sync.getEntityId(),
        sync.getEntityType(), sync.getVersion());
    if (updated == 0) {
        // stale write – drop it silently
    }
}

Thứ hai, ngay cả khi version check hoạt động, vẫn có một lỗ hổng: nếu bản ghi trùng lặp đến sau khi bản ghi gốc của cùng version đã được xử lý, nó sẽ được ghi lại từ đầu – gây ra hiệu ứng “nghiệp vụ chạy hai lần”. Do đó, idempotency (tính lũy đẳng) là nền tảng: mỗi event mang một khóa duy nhất, và trước khi xử lý, hệ thống kiểm tra khóa đó đã tồn tại trong cơ sở dữ liệu dedup chưa. Nếu có, event bị bỏ qua.

Vấn đề hot entity: khóa phân vùng thông minh

Khi pipeline phải xử lý số lượng lớn, việc phân vùng (partitioning) theo entityId có thể gây mất cân bằng nghiêm trọng nếu một số thực thể “nóng” (hot entity) – như một sản phẩm best-seller trong mùa khuyến mãi – nhận lượng event khổng lồ. Với một partition duy nhất, hệ thống sẽ thắt cổ chai ngay lập tức.

Giải pháp là một custom partitioner theo dõi các hot entity và phân tán chúng qua nhiều partition:

if (hotEntities.contains(entityId)) {
    // hot entity: split it finer by entityId + eventType
    String fineKey = entityId + ":" + extractEventType(key);
    return Math.abs(fineKey.hashCode()) % numPartitions;
}

Bộ theo dõi này không được viết cứng: một job nền lấy mẫu tỷ lệ mỗi entity mỗi giờ, đưa entity vào danh sách nóng khi vượt ngưỡng và đưa ra khi nguội bớt. Việc phân tán hot entity có thể tạo ra rủi ro lệch thứ tự, nhưng điều đó hoàn toàn được xử lý bởi version check phía dưới – đây chính là triết lý xuyên suốt bài viết: chỉ được nới lỏng tính thứ tự khi tính đúng đắn được đảm bảo ở một lớp thấp hơn.

Micro-batching: nơi tốc độ thực sự đến từ

Xử lý từng bản ghi một chậm ở hai điểm: một round-trip mạng đến database/API cho mỗi event, và một transaction riêng biệt với chi phí commit. Cả hai đều không tốn CPU – bạn có thể thêm consumer mãi mà thông lượng không đổi.

Giải pháp là gộp batch: tích lũy 100 bản ghi hoặc 50 mili giây (điều kiện nào đến trước), rồi xử lý cả nhóm trong một lần. Sự khác biệt rất rõ rệt: xử lý từng bản ghi đạt khoảng 500 event/giây, còn micro-batching đưa con số này lên khoảng 8.000 event/giây – tăng gấp 16 lần, gần như hoàn toàn nhờ việc gộp 100 round-trip thành một hoặc hai.

So sánh thông lượng trước và sau khi áp dụng micro-batching

Cái giá phải trả là độ trễ thêm tối đa 50ms trong khi chờ batch đầy (chấp nhận được với workload ở mức giây), và vấn đề lỗi batch: nếu một bản ghi trong batch gây lỗi thì các bản còn lại ra sao? Giải pháp là mỗi bản ghi nằm trong savepoint riêng của transaction – một bản ghi lỗi chỉ rollback chính nó, đẩy sang dead-letter queue, còn các bản khác vẫn commit bình thường.

Kích thước batch được tinh chỉnh qua thử nghiệm thực tế: thử 50, 100, 200 và 500. Con số 100 chiến thắng. Vượt qua đó, đường cong thông lượng dẹt lại, và câu lệnh IN trong query dedup trở nên quá dài khiến query planner đưa ra quyết định tồi – lớn hơn không phải lúc nào cũng tốt hơn.

Backpressure: thứ giữ cho hệ thống không tự ăn chính mình

Điều mà một pipeline thông lượng cao thực sự phải sợ không phải là tụt lại phía sau, mà là tụt lại mà không biết. Nếu upstream luôn nhanh hơn downstream, backlog sẽ tăng không giới hạn cho đến khi ổ đĩa đầy hoặc consumer hết bộ nhớ. Vì vậy, hệ thống intake phải có khả năng đẩy ngược (backpressure) ở ba tầng:

1. Tầng 1 – Tự điều chỉnh: Consumer theo dõi độ trễ xử lý của chính nó và giảm tốc độ poll khi thấy mình chậm lại (dùng bộ đếm trượt moving average với ngưỡng 200ms và 50ms).
2. Tầng 2 – Điều tiết từ bên ngoài: Một job riêng theo dõi lag của từng partition, rồi phản hồi giới hạn tốc độ cho các producer thông qua config service. Producer kiểm tra giới hạn trước khi gửi và buffer cục bộ khi bị bóp phanh.
3. Tầng 3 – Ưu tiên nghiệp vụ: Khi downstream thực sự gặp sự cố, các loại event có độ ưu tiên thấp sẽ bị tạm ngừng (vẫn nằm trong hàng đợi nhưng không được tiêu thụ), dồn toàn bộ tài nguyên cho các event quan trọng. Việc xếp hạng ưu tiên phải được quyết định trước khi sự cố xảy ra – không ai có thể đưa ra quyết định hợp lý lúc 2 giờ sáng.

Câu chuyện bug ẩn dưới vỏ bọc timeout

Một bài học đắt giá được chia sẻ: một consumer có connection pool 50 kết nối đến một downstream. Khi downstream tách đọc/ghi thành hai hostname, code được cập nhật nhưng cấu hình pool bị quên – 50 kết nối bị chia đôi, mỗi host chỉ còn 25. Vào giờ cao điểm, pool cạn kiệt, request xếp hàng chờ kết nối, và độ trễ tăng vọt.

Điều khiến bug khó tìm là triệu chứng nói dối: lỗi không phải “connection refused” mà là “request timed out”, vì mọi request đều đang ngồi trong hàng đợi của pool. Độ trễ tail (tail latency) tăng vọt trong khi tỷ lệ lỗi vẫn phẳng lặng – muốn nhận diện được bug này, bạn phải từng thấy signature này một lần rồi. Sau sự cố, nhóm đã thêm giám sát pool (mức sử dụng, độ sâu hàng đợi) và đưa ra quy tắc: mọi thay đổi cấu trúc downstream (tách hostname, thay đổi load-balancer) đều phải thông báo cho đội tích hợp – vì với họ, đó không phải chi tiết triển khai mà là một sự kiện về năng lực.

Một buổi chiều thực chiến: 23.000 event, 13 lỗi, 0 mất mát

Toàn bộ các giải pháp trên không bao giờ hoạt động riêng lẻ. Câu chuyện sau đây cho thấy chúng phối hợp với nhau như thế nào trong một sự cố thực tế:

Lúc 2 giờ chiều, cảnh báo vang lên: lag của consumer thuộc miền đơn hàng tăng từ vài trăm mili giây lên hơn 5 phút, đồng thời tỷ lệ lỗi API ERP tăng từ dưới 1% lên 40%.

Hai phút đầu không ai động vào gì cả. Circuit breaker tự động mở, cắt request đến ERP, event không xử lý được chuyển sang retry queue, và backpressure tự giảm tỷ lệ poll của consumer khoảng 60%. Phòng tuyến đầu hoạt động hoàn toàn tự động.

Từ phút 2 đến phút 10 là chẩn đoán: kỹ sư trực xác nhận lỗi từ phía ERP – một đợt migration database, cần khoảng 30 phút để khôi phục. Từ phút 10 đến phút 15, kỹ sư kích hoạt chính sách loại bỏ tải (shedding) của miền đơn hàng: tạm ngưng các loại event không cốt lõi (review sync, backfill lịch sử) để dồn tài nguyên cho cập nhật trạng thái đơn hàng và tồn kho. Các event cốt lõi chờ trong retry queue cho đến khi ERP hồi phục.

Dòng thời gian xử lý sự cố

Khi ERP phục hồi, circuit breaker chuyển sang trạng thái half-open, thử vài request, xác nhận ổn, rồi đóng lại. Retry queue replay toàn bộ backlog – và vì mọi đường xử lý đều idempotent, việc replay là an toàn tuyệt đối, không cần xử lý đặc biệt cho các bản trùng lặp mà replay tạo ra.

Buổi tối, quá trình đối soát ngoại tuyến (offline reconciliation) đưa ra con số cuối cùng: 23.000 event bị ảnh hưởng, 22.987 được replay và xử lý tự động, 13 event nằm trong dead-letter queue do dữ liệu bẩn phát sinh trong lúc ERP migration (được xử lý thủ công sáng hôm sau). Nghiệp vụ cốt lõi gián đoạn tối đa 2 phút – đúng khoảng thời gian trước khi circuit breaker kích hoạt. Non-core gián đoạn khoảng 40 phút. Zero dữ liệu mất. Toàn bộ chuỗi chỉ có hai quyết định của con người: xác nhận nguyên nhân và chọn loại bỏ tải; mọi thứ khác pipeline tự làm.

So sánh với nghiên cứu học thuật

Tác giả thẳng thắn thừa nhận không có kỹ thuật nào trong bài là hoàn toàn mới. Kỹ thuật chia khóa chủ động cho hot entity có liên hệ với nghiên cứu Partial Key Grouping (Nasir et al., ICDE 2015) và các nghiên cứu mở rộng sau đó về cân bằng tải trong hệ thống xử lý luồng phân tán. Tuy nhiên, khác với các giải pháp học thuật tối ưu hóa sự cân bằng, cách tiếp cận của tác giả là “đủ tốt” – không cần một giao thức điều phối phức tạp mà bạn phải vận hành lúc 2 giờ sáng.

Khái niệm “exactly-once” thực chất là “effectively-once” dựa trên idempotency được kế thừa từ bài viết kinh điển Idempotence Is Not a Medical Condition của Pat Helland. Điểm khác biệt lớn nhất là bối cảnh: nghiên cứu thường giả định bạn kiểm soát hoàn toàn engine xử lý luồng, còn tích hợp doanh nghiệp thì không – bạn phải nói chuyện với những hệ thống ra đời trước pipeline hàng chục năm, và việc loại bỏ tải phải là quyết định ưu tiên nghiệp vụ được đưa ra trước sự cố, không phải chiến lược lấy mẫu mà engine tự chọn trong lúc khủng hoảng.

Bài học rút ra

Tốc độ là yêu cầu thứ ba, không phải thứ nhất. Tính đúng đắn là thứ khiến doanh nghiệp tin tưởng pipeline, khả năng chịu lỗi là thứ giúp bạn ngủ ngon trong lúc hệ thống chạy, và tốc độ chỉ có ý nghĩa khi hai điều trên đã được đảm bảo. Phần khó nhất của công việc tích hợp chưa bao giờ là chọn sơ đồ phân vùng hay kích thước batch, mà là tìm điểm cân bằng giữa ba yếu tố này – vì đẩy một yếu tố đến giới hạn sẽ phải trả giá bằng hai yếu tố còn lại. Kỹ thuật ở đây là tìm điểm đủ tốt cho khối lượng dữ liệu và hệ thống bạn thực sự có – không phải điểm tối ưu trên lý thuyết, mà là điểm phù hợp với thực tế.