HỆ THỐNG ĐỒNG BỘ HEARTBEAT (REAL-TIME SYNC)

Tài liệu mô tả quy trình theo dõi trạng thái hoạt động thực thời (Real-time Sync) của người dùng trên các nền tảng khách hàng.

💡 Thông tin Kỹ thuật (Meta Data):

📍 Route: POST /subc | /api/tracking/choice

💻 Source Frontend: public/js/widget.js (Được nhúng trực tiếp trên Client Site)

⚙️ Source Backend: app/Http/Controllers/SubcController.php

🗄️ Database: Redis (Cache hàng đợi) | MySQL (Bảng subcribers, statistics)

I. Tổng quan chức năng Heartbeat

Hệ thống Heartbeat nhận nhiệm vụ theo dõi trạng thái "Đang Online" (Alive/Sống) của hàng chục ngàn người truy cập (Anonymous Users) trên các Website vệ tinh dùng chung hệ sinh thái.

Cụ thể, thẻ Widget JS được gắn trên trang sẽ gửi một tín hiệu thu nhỏ (Ping) về máy chủ định kỳ 5 phút/lần để làm bằng chứng người dùng vẫn đang cắm máy/truy cập trang trang.

II. Sơ đồ luồng Dữ liệu (Data Flow)

Để dễ hình dung, vòng đời của một luồng xử lý Heartbeat diễn ra như sau:

III. Cơ chế Ghi đè & Tối ưu hóa Hiệu năng

Đây là khâu quan trọng nhất giúp hệ thống không bị "ngập lụt" khi có Traffic lớn làm tắc nghẽn Database:

III.1. Redis Buffering: Giải pháp chống Deadlock

Nếu 10.000 users cùng thực hiện lệnh Ping ghi vào MySQL tại cùng 1 thời điểm, đĩa cứng cơ sở dữ liệu sẽ sụp đổ hoặc xảy ra hiện tượng thắt cổ chai (IO Wait/Deadlock).
=> Giải pháp: Bắn dữ liệu vào Redis (Môi trường Bộ nhớ RAM). Việc ghi log trên RAM diễn ra với tốc độ tíc tắc (Sub-millisecond), giúp Server ôm trọn lượng truy cập đồng thời (Concurrency) khổng lồ mà không tốn lấy 1% tài nguyên Disk.

III.2. Cronjob Batch Insert: Hợp nhất dữ liệu

Cứ mỗi 5 phút, Cronjob sẽ âm thầm chạy ở Background. Thay vì đẩy 10.000 lệnh UPDATE đơn lẻ lên MySQL, Worker sẽ "Gom Nhóm" toàn bộ chúng lại thành một câu truy vấn khổng lồ: INSERT ... ON DUPLICATE KEY UPDATE. Nhờ đó, MySQL chỉ phải tốn công gánh đúng 1 tác vụ duy nhất.

IV. Logic Định danh (Subscriber Identification)

Làm thế nào để hệ thống nhận diện hàng chục vạn người dùng khi họ chẳng cần tài khoản đăng nhập?

Hệ thống sử dụng một thuật toán Băm (Hash) tổ hợp từ IP + UserAgent + Fingerprint Trình duyệt. Khối mã này tạo ra một định danh duy nhất (PAM ID) giúp dán nhãn cố định 1 thiết bị khách hàng ngay từ lần đầu họ truy cập.

IV.2. Phân tách Source Client: Token Verification

Bởi vì hệ thống phục vụ nhiều Website đối tác, nên mỗi Client sẽ được phát 1 Token Khóa Bảo Mật. Trước khi cho phép ghi nhận Heartbeat, Midddleware sẽ tra cứu DB xem Token này có quyền hay không. Điều này đóng sập cửa với nỗ lực giả mạo request rác làm bẩn dữ liệu (Data Pollution).

V. Middleware: CSRF Exclusion & Auth Bypass

Theo cơ chế bảo vệ tiêu chuẩn của Laravel, các truy vấn khác Domain đều sẽ bị chặn ngay lập tức.

Do API /subc trực tiếp nhận dữ liệu đổ về từ hàng trăm vệ tinh bên ngoài (Cross-domain), luồng dữ liệu này KHÔNG THỂ VÀ KHÔNG ĐƯỢC PHÉP vướng vào màng lọc CSRF (Cross-Site Request Forgery).

Chúng tôi đã thiết lập ngoại lệ trong file VerifyCsrfToken.php để chừa riêng endpoint /subc ra ngoài ranh giới CSRF, nhưng bù lại ép nó vào quy trình rà soát Client Token cực gắt gao nêu trên.

VI. Kiểm soát Sai số & Duplicate Data

Hệ thống được thiết lập bộ lọc theo Khung trượt thời gian 5 Phút (Sliding Window). Trong chu kỳ đếm, nếu 1 người dùng "rảnh tay" F5 trang liên tục và Ping 2-3 lệnh Heartbeat gần nhau, khe chứa Redis sẽ chủ động ghi đè (Overwrite) thông số mới đè lên cái cũ, dập tắt tận gốc việc đếm trùng thiết bị (Double Counting) trước khi vòng Cronjob kịp mang số liệu đẩy vào MySQL.

HỆ THỐNG ĐỒNG BỘ HEARTBEAT (REAL-TIME SYNC)

I. Tổng quan chức năng Heartbeat#

II. Sơ đồ luồng Dữ liệu (Data Flow)#

III. Cơ chế Ghi đè & Tối ưu hóa Hiệu năng#

III.1. Redis Buffering: Giải pháp chống Deadlock#

III.2. Cronjob Batch Insert: Hợp nhất dữ liệu#

IV. Logic Định danh (Subscriber Identification)#

IV.1. Cơ chế PAM ID & Cookie Session#

IV.2. Phân tách Source Client: Token Verification#

V. Middleware: CSRF Exclusion & Auth Bypass#

VI. Kiểm soát Sai số & Duplicate Data#