Hệ Thống Tự Phục Hồi (Disparity Recovery): Khi Bot Tự Chữa Lành

Trong thế giới lý tưởng, Bot vào lệnh nào, Sàn nhận lệnh đó.
Trong thế giới thực:
– Mạng rớt đúng lúc gửi lệnh.
– Sàn tự đóng lệnh (Stop Out) vì Margin Call.
– Bạn lỡ tay đóng nhầm lệnh trên điện thoại.

Lúc này, xảy ra Disparity (Sự sai lệch) giữa:
1. Dữ liệu Bot nghĩ (Internal State): “Tao đang có 5 lệnh”.
2. Dữ liệu Sàn có (Broker State): “Mày chỉ còn 4 lệnh thôi”.

Nếu không xử lý, Bot sẽ bị loạn (loạn Logic tính toán).

1. Cơ Chế Phát Hiện (Detection)

Tại hàm OnInit() (khi khởi động) và định kỳ mỗi 1 phút, Bot sẽ chạy quy trình Audit:
1. Đọc DB SQLite -> Lấy số lượng lệnh lý thuyết (Theoretical Count).
2. Quét CInventory -> Lấy số lượng lệnh thực tế (Actual Count).

2. Chiến Lược Phục Hồi (Recovery Strategy)

Nếu Actual != Theoretical, Bot kích hoạt chế độ STATE_RECOVERY.

Kịch bản 1: Thiếu Lệnh (Missing Order)
– DB báo có 5 lệnh, Sàn chỉ có 4.
– Nguyên nhân: Lệnh bị đóng tay hoặc Sàn lỗi.
– Hành động:
– Nếu lệnh mất là lệnh dương -> Coi như đã chốt lời -> Cập nhật DB lại thành 4.
– Nếu lệnh mất là lệnh âm (cắt lỗ ngoài ý muốn) -> MỞ LẠI NGAY LẬP TỨC (Re-open) để đảm bảo trạng thái Hedge của cả chùm lệnh không bị phá vỡ.

Kịch bản 2: Thừa Lệnh (Ghost Order)
– DB báo 5, Sàn có 6.
– Nguyên nhân: Bot lag nên vào đúp 2 lần.
– Hành động: Đóng ngay lệnh thừa (ưu tiên đóng lệnh có lợi nhuận thấp nhất hoặc lệnh mới nhất).

3. Thông Báo Khẩn Cấp

Bất kỳ khi nào Tự Phục Hồi kích hoạt, Bot phải:
– Gửi thông báo Push về điện thoại: “ALERT: Disparity Detected! Auto-healing running…”.
– Ghi Log ERROR vào CAuditManager.

Nhờ hệ thống này, Bot V5 có thể tự vận hành hàng năm trời mà không cần bạn phải can thiệp thủ công mỗi khi mạng chập chờn.

👉 Tiếp theo: Làm sao biết hệ thống tự phục hồi này hoạt động tốt? Chẳng lẽ đợi mạng rớt thật? Không, chúng ta sẽ giả lập lỗi. Xem ngay: Stress & Chaos Testing: Kế Hoạch “Tra Tấn” Bot Trước Khi Go-Live