JSON Persistence, Watchdog và Dashboard: nền vận hành của PyNhiQuaiBot

Một bot giao dịch có thể có công thức vào và thoát lệnh hợp lý nhưng vẫn thất bại vì mất trạng thái, chạy trùng process, treo im lặng hoặc hiển thị dashboard đã cũ như dữ liệu thời gian thực. Với PyNhiQuaiBot, lớp hạ tầng gồm JSON persistence, FSM, log dashboard và watchdog là phần nối logic chiến lược với môi trường VPS.

Trong bản Python, kho GVStore thay vai trò GlobalVariable của MT5. Nó lưu P0, phạm vi step, cờ harvest, stage plow, StartTime, lock và FSM vào file .gv.json. Mỗi tick, bot đọc position từ MetaTrader5, xử lý cluster, vẽ dashboard log rồi lưu state. Thiết kế này dễ triển khai và dễ kiểm tra bằng mắt, nhưng khi đưa Python Bot Auto Trading vào môi trường chạy liên tục, cần củng cố tính nguyên tử, khóa process, version schema, heartbeat và giám sát.

Bài viết thuộc Header Site HNDATA, dành cho đào tạo kỹ thuật. Monitoring không loại bỏ rủi ro thị trường hoặc lỗi broker. HNDATA không cam kết lợi nhuận. Hãy kiểm thử demo, bảo vệ credential và xây quy trình can thiệp thủ công.

1. Stateless và stateful trong bot trading

Giá hiện tại, account info và danh sách position có thể đọc lại từ MT5. Nhưng nhiều dữ liệu chiến lược không thể suy ra chắc chắn:

• ▸P0 ban đầu của cluster;
• ▸step cuối đã xử lý;
• ▸biên step nhỏ nhất/lớn nhất đã đi qua;
• ▸step nào đã gặt X;
• ▸step nào đã đóng bằng plow;
• ▸stage plow đang ở 1, 2 hay 3;
• ▸StartTime của cycle basket;
• ▸số lần reset;
• ▸trạng thái lockdown;
• ▸khóa FSM đang BUSY.

Đó là state. Nếu process restart mà mất state, cùng positions có thể dẫn tới quyết định khác. Persistence không nhằm thay thế broker; nó giữ trí nhớ chiến lược còn broker giữ sự thật execution.

Nguyên tắc đúng là “rebuild what can be rebuilt, persist what cannot, reconcile both”. Position và deal phải đọc lại. P0 và cờ cần lưu. Khi hai nguồn mâu thuẫn, engine phải có chính sách.

2. Cấu trúc GVStore

GVStore dùng dictionary str -> float. Khi khởi tạo, nó đọc JSON UTF-8 và chuyển mọi value sang float. check, get, set, delete, names cung cấp API nhỏ. save tạo thư mục cha và ghi JSON indent.

Ưu điểm:

• ▸không cần database server;
• ▸file đọc được bằng mắt;
• ▸dễ sao lưu;
• ▸phù hợp single process;
• ▸key động thuận tiện cho step;
• ▸tương thích mô hình GlobalVariable trong MQ5.

Giới hạn:

• ▸không có transaction;
• ▸không có lock đa process;
• ▸mọi value bị ép float;
• ▸file hỏng có thể làm state rỗng;
• ▸ghi trực tiếp có thể bị cắt giữa chừng;
• ▸không có schema version;
• ▸không có audit history.

Với prototype hoặc một instance được quản trị tốt, JSON đủ dùng. Với hệ thống sản xuất, cần bọc thêm các bảo vệ.

3. Namespace của state

Prefix được tạo từ:

storage_prefix + symbol + login + magic

Nhờ đó, key P0 của BTCUSD tài khoản A không đè P0 của XAUUSD hoặc tài khoản B. Magic tách cluster Buy và Sell. Ví dụ logic:

NHỊ QUÁI V6_BTCUSD_123456_6111_P0
NHỊ QUÁI V6_BTCUSD_123456_6111_PLOW_STAGE_2

Namespace cần ổn định. Nếu đổi bot_name hoặc storage_prefix giữa cycle, bot có thể tạo namespace mới và bỏ state cũ. Cấu hình production nên tách tên hiển thị khỏi storage ID. Storage ID là định danh kỹ thuật bất biến; label có thể thay.

Tên symbol có dấu chấm hoặc suffix vẫn hợp lệ trong JSON key, nhưng khi xuất metrics cần escape theo chuẩn hệ thống đích.

4. P0, step và khả năng khôi phục

P0 là neo để tính current step và step price. MinStep/MaxStep giới hạn dải đã đi qua. LastStep giúp xác định hướng. Khi khởi động, bot quét positions và parse step từ comment để cập nhật traversed range.

Việc sync từ comment là lớp khôi phục tốt. Tuy nhiên comment có giới hạn 31 ký tự, broker có thể chỉnh hoặc người dùng có thể mở lệnh thủ công. Parser cần test step âm, dương, S0 và comment bất thường.

Nếu JSON mất P0 nhưng còn positions, không nên mặc định lấy Bid mới làm P0 rồi tiếp tục. Step comment được tạo từ P0 cũ; neo mới làm giá logic sai. Chính sách an toàn là dừng cluster, cảnh báo và yêu cầu recovery có kiểm soát. Có thể suy ngược P0 từ giá logic nếu lưu thêm metadata, nhưng giá khớp có slippage nên không chính xác tuyệt đối.

5. Cờ harvest và stage plow

X_CLOSED_{s} và PLOW_CLOSED_{s} ngăn mở lại ngay step vừa thu hoạch. PLOW_STAGE_{s} lưu high-water stage. Những cờ này phải tồn tại qua restart.

Nếu file hỏng và cờ mất, bot có thể mở lại position không mong muốn. Nếu cờ tồn tại quá lâu sau khi position/cycle đã thay đổi, step có thể bị khóa oan. Vì vậy, mỗi key nên có:

• ▸cycle ID;
• ▸loại state;
• ▸step;
• ▸value;
• ▸updated_at;
• ▸optional ticket.

Dictionary float hiện tại tối giản. Một schema JSON cấu trúc sẽ dễ migration và audit hơn, nhưng phức tạp hơn khi tương thích bản cũ. Có thể giữ runtime key-value rồi thêm sidecar journal append-only.

6. FSM chống nhồi trùng

FSM tạo key theo Magic, step và side. BUSY được lưu bằng timestamp milliseconds. Nếu quá năm giây, khóa tự xóa và trở lại READY.

Đây là lease, không phải lock vĩnh viễn. Lease giải quyết crash sau khi set BUSY nhưng trước khi clear. Tuy nhiên năm giây phải lớn hơn thời gian order bình thường và nhỏ hơn thời gian phục hồi chấp nhận được. Khi mạng chậm, order có thể hoàn tất sau timeout; bot mở lại sẽ gây trùng. Cần reconciliation ticket/comment trước retry.

Một FSM production nên có:

READY
SUBMITTING
ACKNOWLEDGED
VERIFYING
FAILED_RETRYABLE
FAILED_FINAL

Mỗi transition log request ID và retcode. Với tần suất thấp, READY/BUSY có thể đủ, nhưng vẫn cần single instance.

7. Atomic write cho JSON

Ghi trực tiếp vào file đích có rủi ro: process hoặc VPS tắt khi file đang ghi, để lại JSON thiếu. Lần khởi động sau bắt exception và dùng dictionary rỗng; đây là hành vi dễ dẫn đến giao dịch sai.

Quy trình atomic write:

1. ▸serialize state;
2. ▸ghi vào file tạm cùng filesystem;
3. ▸flush buffer;
4. ▸fsync nếu cần;
5. ▸replace file đích bằng thao tác atomic;
6. ▸giữ một backup phiên trước;
7. ▸cập nhật checksum.

Trên Windows, replace có chi tiết quyền và antivirus lock cần test. File tạm nên có tên cố định theo instance hoặc UUID, không dùng chung.

Khi load thất bại, không nên âm thầm state rỗng nếu account còn positions. Chuyển sang SAFE_STOP, phát cảnh báo và thử backup. “Fail closed” phù hợp hơn “tiếp tục với trí nhớ trắng”.

8. Schema version và migration

State thay đổi theo phiên bản bot. Nếu thêm field, đổi key hoặc đổi đơn vị timestamp, file cũ có thể bị hiểu sai. JSON nên có metadata:

{
  "schema_version": 2,
  "bot_version": "6.x",
  "instance_id": "btc-main",
  "updated_at": "2026-07-12T10:00:00Z",
  "data": {}
}

Migration phải:

• ▸backup trước;
• ▸kiểm tra version nguồn;
• ▸chuyển đổi deterministic;
• ▸validate invariant;
• ▸ghi file mới atomic;
• ▸log kết quả;
• ▸không downgrade tự động.

Nếu migration thất bại, dừng bot. Không chỉnh JSON bằng tay khi process đang chạy.

9. Single-instance lock

JSON không bảo vệ hai process. Cả hai có thể load cùng state, cùng nhìn FSM READY, cùng gửi order rồi ghi file theo thứ tự cuối cùng. Lost update có thể xóa cờ của process kia.

Mỗi instance cần mutex:

• ▸Windows named mutex;
• ▸file lock có PID;
• ▸service manager bảo đảm một process;
• ▸port bind độc quyền;
• ▸database advisory lock.

Lock cần gắn login, symbol và Magic set, không chỉ tên script. Hai instance khác symbol có thể hợp lệ nếu file và tài nguyên tách biệt.

Khi thấy lock cũ, kiểm tra PID còn sống trước khi thu hồi. Không xóa lock mù quáng. Dashboard phải báo duplicate start attempts.

10. Heartbeat là gì?

Heartbeat là dấu hiệu bot còn sống và vòng xử lý còn tiến triển. Chỉ kiểm tra process tồn tại chưa đủ; process có thể treo. Heartbeat nên chứa:

• ▸timestamp UTC cuối;
• ▸tick timestamp cuối;
• ▸loop duration;
• ▸MT5 connected;
• ▸account login/server;
• ▸symbol tick age;
• ▸state RUNNING/LOCKED/CLOSING/SAFE_STOP;
• ▸last successful order;
• ▸last error;
• ▸JSON save success.

Bot cập nhật heartbeat sau một vòng thành công. Watchdog bên ngoài đọc nó. Không để watchdog dùng chung event loop với bot; nếu loop treo, watchdog nội bộ cũng treo.

Heartbeat cần atomic write hoặc metrics endpoint. Timestamp phải được đánh giá cùng clock sync.

11. Watchdog cần phân biệt “sống” và “khỏe”

Một watchdog tối thiểu:

1. ▸kiểm tra process/service;
2. ▸kiểm tra heartbeat age;
3. ▸kiểm tra MT5 process;
4. ▸kiểm tra terminal login;
5. ▸kiểm tra tick age;
6. ▸kiểm tra disk space;
7. ▸kiểm tra JSON parse;
8. ▸kiểm tra duplicate instance;
9. ▸kiểm tra order failure rate;
10. ▸gửi cảnh báo.

Không restart ngay mọi lỗi. Nếu market đóng, tick age cao là bình thường. Nếu credential sai, restart vô hạn không sửa được. Nếu JSON corrupt và còn positions, tự restart có thể nguy hiểm.

Phân loại:

• ▸transient: retry/restart có backoff;
• ▸market state: chờ và báo thông tin;
• ▸config/auth: dừng, cần người xử lý;
• ▸state corruption: safe stop, khóa auto restart;
• ▸risk event: cảnh báo khẩn, không tự tiện thay chiến lược.

12. Chính sách restart an toàn

Service manager có thể restart khi process crash. Trước khi bot giao dịch lại, startup sequence phải:

1. ▸lấy instance lock;
2. ▸load config;
3. ▸validate JSON/checksum;
4. ▸initialize MT5;
5. ▸xác minh login/server;
6. ▸select symbol;
7. ▸đọc positions/history;
8. ▸reconcile state;
9. ▸kiểm tra spread/tick age;
10. ▸chuyển RUNNING.

Nếu bất kỳ bước quan trọng thất bại, bot ở SAFE_STOP. Restart loop nên exponential backoff và có ngưỡng circuit breaker.

Không cấu hình watchdog “kill – start” mỗi phút khi heartbeat cũ mà không thu thập dump/log. Việc đó che nguyên nhân và có thể tạo lệnh trùng.

13. Dashboard hiện tại và hướng mở rộng

PyNhiQuaiBot log dashboard khoảng hai lần mỗi giây. Nó hiển thị account, equity, balance, full hedge, floating, P0, Buy/Sell volume và bias của hai cluster, cùng bias tổng symbol.

Đây là lớp quan sát trực tiếp hữu ích. Nhưng log console không phải dashboard lịch sử. Nâng cấp có thể tách:

• ▸collector tạo snapshot;
• ▸API read-only;
• ▸UI web;
• ▸time-series metrics;
• ▸alert manager.

Trading loop không nên render HTML hoặc chờ network dashboard. Nó chỉ ghi snapshot nhanh. Dashboard đọc bất đồng bộ.

14. Data freshness trên dashboard

Mọi widget phải có observed_at. Nếu heartbeat quá hạn, UI hiển thị STALE và làm mờ số. Không tiếp tục animate như dữ liệu live.

Các ngưỡng freshness khác nhau:

• ▸tick age;
• ▸account info age;
• ▸positions age;
• ▸history scan age;
• ▸state save age;
• ▸dashboard fetch age.

Balance mới nhưng positions cũ vẫn có thể tạo tổng sai. Snapshot nên được tạo nhất quán trong một vòng và có sequence number.

15. Chỉ số dashboard nên có

Account

Login, server, balance, equity, margin, free margin, margin level.

Cluster

Magic, P0, current step, traversed range, realized, floating, basket total/target, Buy volume, Sell volume, bias, gross, position count.

Harvest

HitXCount, số X_CLOSED, số PLOW_CLOSED, stage counts và close gần nhất.

Risk

Bias limit, max positions, lockdown threshold, trạng thái frozen, lệnh LOCKDOWN_ABS.

Runtime

Uptime, heartbeat age, loop latency percentile, MT5 connected, spread, tick age, JSON save status, disk space.

Execution

Order success/reject, retcode gần nhất, slippage, close pending.

Không đưa credential hoặc đường dẫn chứa secret lên UI.

16. Dashboard read-only và kênh điều khiển

Một lỗi bảo mật phổ biến là thêm nút Close All vào dashboard không có xác thực. Dashboard công khai trên port VPS có thể bị quét.

Thiết kế an toàn:

• ▸bind localhost;
• ▸reverse proxy HTTPS;
• ▸VPN hoặc Zero Trust;
• ▸xác thực mạnh;
• ▸phân quyền read/operator/admin;
• ▸CSRF protection;
• ▸confirmation challenge;
• ▸audit log;
• ▸rate limit;
• ▸tách API read và command;
• ▸command queue có signature/idempotency.

Các thao tác unlock, đổi lot, reset P0 và close basket cần hai bước. Không cho chỉnh raw JSON qua web.

17. Log có cấu trúc

Log text dễ đọc nhưng khó truy vấn. Structured log nên có field:

timestamp, level, event, instance_id, login, symbol, magic,
cycle_id, step, side, ticket, volume, price, net, retcode,
state_before, state_after, latency_ms

Event name ổn định như ORDER_SUBMITTED, ORDER_REJECTED, HARVEST_X, PLOW_STAGE, BASKET_TRIGGER, LOCKDOWN, STATE_SAVE_FAILED.

Không log mỗi tick ở mức INFO nếu tạo quá nhiều dữ liệu. Dùng sampling, metrics và log khi state đổi. Thiết lập rotation, retention và disk alert.

18. Cảnh báo hữu ích, không gây mệt mỏi

Cảnh báo nên có severity và dedup:

• ▸Critical: state corrupt còn open positions, account mismatch, margin nguy hiểm;
• ▸High: heartbeat stale khi market open, hedge order fail;
• ▸Medium: order rejects liên tiếp, spread cao kéo dài;
• ▸Low: dashboard unavailable, backup chậm.

Mỗi alert trả lời: chuyện gì, instance nào, bắt đầu lúc nào, exposure hiện tại, hành động đề xuất. Cảnh báo lặp mỗi tick sẽ bị bỏ qua. Dùng cooldown và gửi recovery notification.

19. Backup và khôi phục

Backup JSON theo version, nhưng không restore tự động file cũ mà không đối chiếu positions. Runbook:

1. ▸dừng service;
2. ▸xác minh không instance nào chạy;
3. ▸lưu snapshot account/positions/history;
4. ▸backup file hỏng;
5. ▸chọn bản restore;
6. ▸kiểm tra login/symbol/Magic;
7. ▸reconcile P0, step, cờ và cycle;
8. ▸chạy dry-run/read-only;
9. ▸khởi động demo hoặc giám sát chặt;
10. ▸ghi biên bản.

State backup không thay thế report broker. Cần lưu config version cùng state.

20. Test chaos cho persistence và watchdog

Các bài test nên gồm:

• ▸kill process lúc đang save;
• ▸làm JSON thiếu dấu ngoặc;
• ▸disk full;
• ▸file permission denied;
• ▸MT5 đóng;
• ▸terminal mất login;
• ▸tick ngừng nhưng process còn sống;
• ▸API call treo;
• ▸hai instance khởi động cùng lúc;
• ▸clock nhảy;
• ▸network chập chờn;
• ▸order timeout nhưng broker đã khớp;
• ▸dashboard mất kết nối;
• ▸watchdog restart nhiều lần.

Mục tiêu không phải bot không bao giờ lỗi, mà lỗi chuyển sang trạng thái dự đoán được, không tự mở lệnh thiếu bối cảnh và phát cảnh báo đủ thông tin.

21. Lựa chọn JSON, SQLite hay database server

JSON phù hợp một instance, state nhỏ và nhu cầu triển khai đơn giản. SQLite thêm transaction, query và journal nhưng vẫn là file local. PostgreSQL phù hợp nhiều service, audit và dashboard, đổi lại tăng vận hành.

Không cần nâng cấp chỉ vì “database chuyên nghiệp hơn”. Chọn theo failure model:

• ▸một bot trên một VPS: JSON atomic + lock có thể đủ;
• ▸nhiều bot cần lịch sử: SQLite;
• ▸nhiều node/dashboard/team: database server.

Dù dùng gì, broker reconciliation vẫn cần. Database không biết order thực tế nếu integration bị lỗi.

22. Checklist production

• ▸state có schema version;
• ▸save atomic và backup;
• ▸load lỗi dẫn SAFE_STOP;
• ▸namespace có login/symbol/Magic;
• ▸storage ID bất biến;
• ▸single-instance lock;
• ▸heartbeat ngoài trading log;
• ▸watchdog chạy độc lập;
• ▸restart có backoff;
• ▸startup reconciliation;
• ▸dashboard báo stale;
• ▸API read-only mặc định;
• ▸command có auth/audit;
• ▸log rotation;
• ▸disk alert;
• ▸NTP hoạt động;
• ▸secret không nằm trong log/repo;
• ▸chaos test đã chạy;
• ▸runbook recovery đã diễn tập;
• ▸không cam kết lợi nhuận từ uptime.

23. Phân quyền thay đổi cấu hình

State cho biết bot đang ở đâu; config quyết định bot sẽ làm gì. Hai loại file phải tách biệt. Nếu dashboard hoặc một script tùy ý có thể sửa lot, Magic, step và equity threshold trong lúc bot chạy, audit của state không còn nhiều ý nghĩa.

Mỗi thay đổi cấu hình nên có người yêu cầu, người phê duyệt, diff trước/sau, thời điểm áp dụng và version. Các thay đổi rủi ro như lot, max positions, lockdown threshold chỉ áp dụng ở maintenance window hoặc cycle mới. Bot đọc config một lần lúc startup sẽ dễ kiểm soát hơn hot reload. Nếu hỗ trợ hot reload, chỉ một allowlist field được đổi và phải validate toàn bộ invariant.

Config parser cần từ chối số âm, NaN, Magic trùng, symbol rỗng, sleep quá nhỏ và đường dẫn state không ghi được. Validation phải xảy ra trước mt5.initialize hoặc trước khi chuyển RUNNING. Không tự sửa giá trị sai sang mặc định mà không cảnh báo, vì người vận hành có thể tưởng giới hạn của họ đang có hiệu lực.

24. SLO cho hệ thống quan sát

Monitoring cũng cần mục tiêu dịch vụ. Ví dụ, khi thị trường mở, 99% heartbeat có tuổi dưới ba giây; alert critical được gửi trong một phút; dashboard snapshot không cũ hơn năm giây; state save thất bại phải được phát hiện trong một vòng.

SLO không phải cam kết lợi nhuận. Nó đo khả năng quan sát. Từ SLO, nhóm xác định alert: một heartbeat trễ nhẹ chưa cần gọi người trực, nhưng nhiều lần liên tiếp hoặc process không còn thì cần escalation.

Theo dõi chính hệ thống monitoring: lần alert test gần nhất, kênh gửi còn hoạt động, dung lượng metrics và certificate dashboard sắp hết hạn. Một watchdog im lặng vì token thông báo hết hạn tạo cảm giác an toàn giả.

25. Quyền riêng tư và bảo mật dữ liệu

Dashboard giao dịch chứa thông tin nhạy cảm: login, balance, equity, chiến lược, symbol và lịch sử. Dù không có password, dữ liệu này vẫn không nên công khai. Mask account ID, mã hóa khi truyền, giới hạn retention và kiểm soát ai được xem.

State JSON không nhất thiết chứa credential nhưng tiết lộ cấu trúc chiến lược. ACL chỉ cho service user và quản trị viên được đọc. Backup rời VPS cần mã hóa. Log gửi sang dịch vụ bên thứ ba phải được xem xét về vùng dữ liệu và chính sách lưu giữ.

API metrics công khai có thể bị lợi dụng để biết bot đang locked hoặc exposure lớn. Không đặt endpoint trên 0.0.0.0 nếu chưa có firewall và auth. Với Prometheus, dùng mạng riêng hoặc agent push có xác thực.

26. Dry-run và chế độ quan sát

Một chế độ read-only rất hữu ích sau nâng cấp hoặc recovery. Bot thực hiện initialize, load state, đọc positions, tính bias, basket và action dự kiến nhưng không gọi order_send. Mỗi action được log là WOULD_OPEN, WOULD_CLOSE hoặc WOULD_LOCK.

Dry-run không thay thế demo vì không kiểm tra broker execution. Nó giúp xác minh state và config trước khi mở quyền giao dịch. Sau restore JSON, chạy read-only trong vài vòng để phát hiện P0 sai, Magic không khớp và dashboard bất thường.

Để tránh vô tình chạy dry-run như production, dashboard phải có banner rõ và heartbeat ghi mode. Ngược lại, REAL mode cũng cần banner nổi bật. Chuyển mode là thao tác được audit, không phải query parameter trên web.

27. Câu hỏi thường gặp

JSON có đủ tin cậy để chạy bot không?

Có thể đủ cho một instance nếu atomic write, lock, backup và reconciliation tốt. Ghi trực tiếp không bảo vệ là chưa đủ cho production.

Tại sao không suy state hoàn toàn từ positions?

Positions không chứa chắc chắn P0, stage plow, cờ closed, StartTime và FSM. Comment chỉ mang một phần thông tin.

Watchdog có nên tự restart mọi lúc?

Không. State corrupt, auth sai hoặc account mismatch cần safe stop. Restart vô hạn có thể làm sự cố nặng hơn.

Dashboard có được quyền đóng lệnh không?

Nên read-only mặc định. Nếu có command, cần HTTPS/VPN, xác thực, phân quyền, xác nhận và audit.

Mất JSON khi còn lệnh phải làm gì?

Dừng mở mới, snapshot broker, khôi phục backup hoặc recovery có kiểm soát. Không tạo P0 mới rồi chạy tiếp mù quáng.

Uptime cao có nghĩa bot an toàn không?

Không. Process sống có thể treo hoặc state sai. Cần health, risk metrics và reconciliation.

Monitoring có cải thiện lợi nhuận không?

Monitoring cải thiện khả năng phát hiện và xử lý lỗi; nó không bảo đảm kết quả thị trường.

28. Kết luận

JSON persistence giữ trí nhớ, FSM giảm hành động trùng, heartbeat chứng minh vòng lặp còn tiến triển, watchdog phát hiện bất thường và dashboard biến state thành thông tin vận hành. Năm thành phần này làm nền cho PyNhiQuaiBot chạy liên tục trên VPS.

Một Python Bot Auto Trading đáng tin không phải bot “không bao giờ lỗi”, mà là bot phát hiện lỗi, dừng an toàn, khôi phục có kiểm soát và để lại audit. JSON cần atomic, process cần lock, dashboard cần freshness, watchdog cần hiểu ngữ cảnh và mọi state phải đối chiếu với MetaTrader5.

Tìm hiểu giải pháp tại PyNhiQuaiBot HNDATA. Trao đổi dashboard, watchdog, VPS và phạm vi tùy biến tại Báo giá HNDATA.

Tuyên bố rủi ro: HNDATA không cam kết lợi nhuận hay hoạt động không gián đoạn. Lỗi phần mềm, hạ tầng, broker và thị trường đều có thể gây thiệt hại. Người dùng chịu trách nhiệm kiểm thử, bảo mật và quản trị vốn.

Xem Bot PyNhiQuaiBotNhận báo giá