Logic tổng thể
1.
Thay vì chạy các Script độc lập, hệ thống nên sử dụng một bộ điều phối tập trung (như Asynq trong LARAVEL và Redis QueueJob):
Scheduler: Định nghĩa tần suất quét (ví dụ: mỗi 1s).
Queue Manager: Đẩy các "Task" vào hàng đợi. Điều này giúp tách biệt việc "gọi API" và "ghi vào DB", tránh việc một worker bị treo làm hỏng cả chu kỳ quét.
2.
Hệ thống Cronjob sẽ vận hành theo mô hình Extract - Transform - Load:
3. Cơ Chế Kiểm Soát Trạng Thái (State Management)
Để tránh việc các Cronjob chạy chồng chéo (Overlap) hoặc xử lý trùng lặp dữ liệu:
Atomic Locking: Sử dụng Redis Lock để đảm bảo tại một thời điểm chỉ có một Worker xử lý một trận đấu cụ thể.
Checksum/Hashing: Trước khi Update vào DB, hệ thống so sánh Hash của dữ liệu mới với dữ liệu cũ. Nếu không có thay đổi (ví dụ: tỉ số vẫn là 0-0), Worker sẽ bỏ qua bước ghi để tiết kiệm tài nguyên.
Retry Strategy: Nếu gọi API thất bại, hệ thống tự động thử lại với cơ chế Exponential Backoff (thời gian chờ tăng dần).
Dead Letter Queue (DLQ): Những Task thất bại quá nhiều lần sẽ được đẩy vào một hàng đợi riêng để lập trình viên kiểm tra thủ công, thay vì làm dừng toàn bộ hệ thống.
Logging & Monitor: Theo dõi thời gian thực hiện (Execution Time) của mỗi Job để phát hiện sớm các truy vấn DB đang bị chậm.
2. Kiến trúc xử lý dữ liệu
3. Luồng dữ liệu chính
1.
Hệ thống được thiết kế theo mô hình xử lý bất đồng bộ nhằm tối ưu hiệu năng khi làm việc với dữ liệu lớn từ API bên thứ ba.
2.
3.
4.
✅ Xử lý bất đồng bộ (Async)
✅ Scale dễ dàng bằng worker
✅ Giảm tải database nhờ Redis
✅ Phù hợp dữ liệu realtime
✅ Tăng hiệu năng API response
5.
Nguyên nhân:
Nhiều job update cùng dữ liệu
Giải pháp:
Chunk nhỏ dữ liệu
Sắp xếp trước khi insert
Retry khi fail
Giải pháp:
Unique key
upsert
Generate OddsID
Giải pháp:
Batch job
Delay job
Queue priority
Giải pháp:
Thêm sleep
Retry + exponential backoff
Modified at 2026-03-27 08:18:14