Một bot giao dịch nhiều tầng không thể chỉ nhớ position đang mở. Nó còn phải nhớ P0 của chu kỳ, Step nhỏ nhất và lớn nhất đã đi qua, stage trailing, tầng đã chốt, thời điểm bắt đầu Basket TP, cờ full hedge lockdown và khóa FSM chống lệnh trùng. Trong EA MQL5, Nhi Quái V6 dùng GlobalVariableSet, GlobalVariableGet, GlobalVariableCheck và GlobalVariableDel. Khi port sang Python, GVStore JSON Python Bot được xây để cung cấp API tương tự bằng dictionary và file JSON local.

Giải pháp này làm bản port PyNhiQuaiBot dễ hiểu: logic chiến thuật gần như giữ nguyên tên thao tác state. Nhưng “ghi dictionary ra JSON” chưa tương đương hoàn toàn với MT5 GlobalVariables. Hai cơ chế khác nhau về phạm vi, transaction, concurrency, kiểu dữ liệu, độ bền, khả năng quan sát và hành vi khi file hỏng. Nếu không nhận ra khác biệt, bot có thể chạy bình thường hàng ngày nhưng mất state đúng lúc restart hoặc hai instance ghi cùng file.

Bài viết phân tích vai trò của GVStore, so sánh hai nền tảng và đề xuất kiến trúc state đáng tin hơn cho Python Bot Auto Trading. Nội dung nhằm học kỹ thuật, không phải tín hiệu giao dịch hay lời hứa lợi nhuận.

1. Vì sao Global State là phần của thuật toán?

Trong script đơn giản, người mới thường nghĩ state chỉ là vài biến tạm. Với Nhi Quái V6, state quyết định hành động tương lai:

• _P0 xác định lưới giá;
• _LastStep giúp nhận biết hướng di chuyển;
• _MinStep và _MaxStep xác định vùng tầng cần quét;
• _X_CLOSED_s ngăn mở lại tầng đã gặt X;
• _PLOW_STAGE_s nhớ mốc trailing cao nhất;
• _PLOW_CLOSED_s ngăn mở bù sau thu quân;
• _FSM_s_B/S giữ chỗ khi gửi lệnh;
• _StartTime giới hạn history cho Basket TP;
• _LOCKED đóng băng cụm khi equity thấp;
• _ResetCount và _HitXCount phục vụ dashboard/audit.

Nếu những giá trị này mất, bot không chỉ mất số liệu hiển thị. Nó có thể đổi P0, mở lại Step đã đóng, quên stage trailing hoặc chạy core trong khi cụm đáng lẽ frozen. Vì vậy persistence là thành phần của correctness.

Một nguyên tắc quan trọng:

Position tại broker là sự thật về exposure; Global State là sự thật về ý định và tiến trình chiến thuật.

Hai nguồn phải được đối soát. Không nguồn nào tự đủ cho toàn bộ quyết định.

2. MT5 GlobalVariables hoạt động ra sao trong EA?

Terminal Global Variables là kho key-value do terminal MT5 quản lý. EA gọi:

GlobalVariableSet(name, value)
GlobalVariableGet(name)
GlobalVariableCheck(name)
GlobalVariableDel(name)
GlobalVariablesTotal()
GlobalVariableName(index)

Giá trị cơ bản là double, nên Nhi Quái V6 biểu diễn timestamp, counter, boolean và enum dưới dạng số. Terminal chịu trách nhiệm lưu dữ liệu ngoài vòng đời của một lần chạy EA. Nhiều EA trong cùng terminal có thể nhìn thấy biến nếu biết tên.

Ưu điểm:

• API có sẵn trong MQL5;
• persistence do terminal quản lý;
• thao tác từng key ngắn gọn;
• dễ duyệt và xóa theo prefix;
• phù hợp mapping các flag/counter số;
• không phải tự xử lý đường dẫn file.

Giới hạn:

• chỉ có kiểu double;
• namespace là quy ước tên, không có cấu trúc object;
• nhiều EA có thể va chạm key;
• transaction nhiều key không nguyên tử;
• khó lưu metadata phức tạp;
• phụ thuộc terminal cụ thể;
• việc export, version schema và migration không thuận tiện;
• state chiến thuật vẫn có thể lệch positions broker.

GlobalVariables tiện lợi nhưng không phải cơ sở dữ liệu ACID. Khi reset xóa nhiều key, EA vẫn có thể dừng giữa chuỗi thao tác.

3. GVStore của PyNhiQuaiBot

Bản Python định nghĩa lớp GVStore:

• data: Dict[str, float];
• _load() đọc JSON nếu file tồn tại;
• save() tạo thư mục và ghi toàn bộ dictionary;
• check(name) kiểm tra key;
• get(name, default) trả float;
• set(name, value) gán float trong memory;
• delete(name) xóa key;
• names() trả danh sách key.

Đường dẫn mặc định là file cùng tên script với suffix .gv.json, ví dụ:

bot_nhi_quai_v6_pro.gv.json

Người dùng có thể truyền --gv để chọn path khác. Trong constructor, file được load một lần. Trong on_tick(), bot gọi gv.save() sau khi xử lý.

Thiết kế này cố ý map gần 1-1 với GlobalVariable API để giảm thay đổi logic. Đây là chiến lược port hợp lý ở giai đoạn đầu: tạo compatibility layer, sau đó cải tiến implementation phía dưới.

JSON mẫu về mặt khái niệm

{
  "NHỊ QUÁI V6_BTCUSD_123456_6111_P0": 60123.5,
  "NHỊ QUÁI V6_BTCUSD_123456_6111_LastStep": 4.0,
  "NHỊ QUÁI V6_BTCUSD_123456_6111_PLOW_STAGE_4": 2.0,
  "NHỊ QUÁI V6_BTCUSD_123456_6112_LOCKED": 1.0
}

Thực tế login và symbol thay đổi theo môi trường. Prefix giúp một file chứa state của nhiều cụm mà vẫn phân biệt.

4. So sánh phạm vi và vòng đời

MT5 GlobalVariables

Phạm vi gắn với terminal. Nếu chạy EA trên terminal khác hoặc cài lại, state không tự đi theo. Nhiều chart/EA trong terminal có thể truy cập cùng kho.

GVStore JSON

Phạm vi gắn với file path. Copy file sang máy khác có thể mang state theo, nhưng cũng có thể vô tình áp state tài khoản cũ vào tài khoản mới. Hai process dùng cùng path chia sẻ file mà không có coordinator.

Sự khác biệt dẫn tới câu hỏi deployment:

• một account/symbol/strategy có một file riêng hay chung?
• path nằm trong source folder, data folder hay volume riêng?
• backup và retention thế nào?
• khi deploy phiên bản mới, file state có được giữ?
• nếu chạy service bằng user khác, quyền file ra sao?

Đặt file cạnh script thuận tiện cho demo, nhưng production thường tách code read-only và data volume writable.

5. Namespace: hàng rào đầu tiên chống đọc nhầm state

gv_prefix() của PyNhiQuaiBot ghép:

storage_prefix + symbol + login + magic

Đây là quyết định tốt vì cùng bot có thể chạy:

• nhiều symbol;
• nhiều tài khoản;
• hai cụm Buy/Sell;
• nhiều phiên bản chiến thuật nếu storage_prefix khác.

Ví dụ, key P0 của Magic 6111 không đè P0 của 6112. Login ngăn demo account đọc state live account.

Tuy nhiên, prefix dạng string vẫn có rủi ro:

• symbol broker đổi suffix, ví dụ BTCUSD và BTCUSD.a;
• bot name chứa ký tự Unicode, normalization khác nhau;
• storage_prefix bị đổi khi nâng phiên bản;
• Magic bị cấu hình trùng;
• login chưa đọc được nên bằng 0 lúc tạo key;
• delimiter xuất hiện trong tên;
• account server khác nhưng login số trùng.

Namespace mạnh hơn nên gồm broker/server và strategy instance UUID, serialize theo schema thay vì chỉ nối chuỗi. Ví dụ identity:

{server, login, symbol, strategy_id, magic, cycle_id}

Key hiển thị có thể được hash hoặc encode ổn định.

6. Kiểu dữ liệu: double tương thích nhưng hạn chế

GVStore ép mọi value thành float, tương đồng MT5 GlobalVariables. Điều này làm port dễ, nhưng Python có khả năng biểu diễn dữ liệu phong phú hơn mà chưa được dùng.

Các vấn đề khi dùng float:

• integer ticket lớn có thể mất độ chính xác nếu vượt giới hạn biểu diễn chính xác;
• timestamp millisecond và counter dài hạn có rủi ro;
• boolean 0/1 không tự mô tả;
• enum stage không có validation;
• không lưu reason, status text hoặc metadata;
• số tiền so sánh float có sai số biên.

Một schema JSON bản địa có thể dùng:

{
  "schema_version": 2,
  "instance": {
    "server": "Demo",
    "login": 123456,
    "symbol": "BTCUSD",
    "magic": 6111
  },
  "cluster": {
    "cycle_id": "uuid",
    "status": "LOCKED_CONFIRMED",
    "p0": "60123.50",
    "last_step": 4,
    "locked_at": "2026-07-12T10:00:00Z"
  }
}

Số tiền có thể lưu decimal string; datetime theo ISO UTC; status là enum. Dù vậy, chuyển schema cần migration và test. Compatibility layer vẫn có thể cung cấp get/set cho logic cũ.

7. Vấn đề lớn nhất: save không atomic

Implementation hiện tại:

self.path.write_text(json.dumps(self.data, ...))

Thao tác ghi đè file có thể bị gián đoạn. Nếu process hoặc máy chết giữa lúc ghi, file có thể rỗng hoặc chỉ có một phần JSON. Lần khởi động sau _load() bắt exception và đặt data = {}. Bot tiếp tục với state rỗng mà không phân biệt “chưa từng có state” với “state vừa bị hỏng”.

Đây là fail-open nguy hiểm. Với trading state, lỗi persistence nên dẫn tới:

• log critical;
• backup file hỏng để điều tra;
• thử đọc bản backup gần nhất;
• chuyển bot sang RECOVERY_REQUIRED;
• không mở lệnh mới;
• reconcile positions từ broker;
• yêu cầu xử lý rõ ràng.

Atomic write đề xuất

Quy trình:

1. serialize state vào file tạm cùng filesystem;
2. flush buffer;
3. fsync file;
4. rename/replace file tạm thành file chính;
5. tùy yêu cầu, fsync thư mục;
6. giữ một backup phiên trước.

Rename cùng filesystem thường atomic hơn ghi đè trực tiếp. Trên Windows cần dùng API/semantics phù hợp và xử lý antivirus/file lock. Test crash injection là cần thiết.

8. Concurrency: hai process có thể làm mất dữ liệu

Giả sử process A và B cùng load file ban đầu {x: 1}.

• A set a = 10;
• B set b = 20;
• A save {x:1,a:10};
• B save {x:1,b:20}.

Key a mất dù không có exception. Đây là lost update.

MT5 GlobalVariables thao tác từng key qua terminal nên mô hình cạnh tranh khác, nhưng transaction nhiều bước vẫn có race. Với JSON whole-file, rủi ro càng rõ.

Các lựa chọn:

• bảo đảm chỉ một writer bằng deployment lock;
• file lock quanh read-modify-write;
• mỗi instance một file riêng;
• SQLite transaction;
• Redis/database với compare-and-set;
• event journal append-only với single consumer.

File lock phải có timeout và xử lý stale lock. Chỉ lock lúc save() chưa đủ nếu hai process giữ dictionary cũ; cần lock toàn bộ read-modify-write hoặc reload/merge có version.

Optimistic concurrency

Lưu revision. Khi save, kiểm tra revision trên disk vẫn bằng revision đã load. Nếu khác, từ chối ghi và yêu cầu merge/retry. Cách này phát hiện lost update nhưng không tự giải quyết xung đột.

Trong bot giao dịch, tốt nhất tránh nhiều writer cho cùng strategy state. Leader election hoặc process lock nên được kiểm tra trước khi on_init().

9. Tần suất save mỗi tick: bền hơn hay tốn hơn?

PyNhiQuaiBot save cuối mỗi tick. Với tick_sleep = 0,25, lý thuyết có thể ghi khoảng bốn lần mỗi giây dù state không đổi. Lợi ích là cửa sổ mất state nhỏ. Nhược điểm:

• I/O không cần thiết;
• tăng xác suất va chạm;
• tạo tải cho disk/antivirus;
• log lỗi quyền có thể lặp;
• không có batching ưu tiên.

Thiết kế tốt hơn dùng dirty flag:

• set/delete chỉ đánh dấu dirty khi value thực sự đổi;
• chuyển trạng thái quan trọng flush ngay;
• thay đổi dashboard counter có thể debounce;
• snapshot định kỳ;
• shutdown flush;
• journal event quan trọng trước action hoặc ngay sau confirmation.

Durability cần phân cấp. _LOCKED, PLOW_STAGE và RESETTING quan trọng hơn last_draw. Không nhất thiết mọi dữ liệu dùng một cơ chế.

10. Reconcile: JSON không phải nguồn sự thật cuối cùng

Khi startup, có bốn tình huống:

1. JSON và broker positions khớp;
2. JSON có state nhưng positions không còn;
3. positions tồn tại nhưng JSON thiếu;
4. cả hai tồn tại nhưng mâu thuẫn.

Bot phải có quy tắc cho từng trường hợp.

JSON có PLOW_STAGE nhưng ticket đã đóng

Stage stale. Không được áp cho position mới cùng Step. Archive/xóa state sau khi xác nhận history.

Position tồn tại nhưng P0 mất

Không nên tùy tiện đặt P0 bằng current Bid rồi gán các position cũ vào lưới mới. Có thể phục hồi P0 từ comment/step và fill price nếu đặc tả cho phép, hoặc chuyển recovery thủ công.

Có LOCKDOWN_ABS nhưng _LOCKED mất

Không nên coi cụm NORMAL. Position comment cho thấy có chân khóa; bot cần tái dựng state hoặc dừng để xác minh.

_LOCKED = 1 nhưng không có hedge

Có thể order đã thất bại, người dùng đóng tay hoặc JSON stale. Giữ dừng mở mới, tính residual và quyết định retry/cảnh báo.

FSM BUSY quá timeout

PyNhiQuaiBot tự xóa sau 5 giây. Trước khi retry open, phải đọc positions/deals vì request cũ có thể đã khớp.

Reconcile nên tạo report và không sửa âm thầm những mâu thuẫn nguy hiểm.

11. Reset state theo prefix và nguy cơ xóa quá rộng

reset_cluster() duyệt gv.names() và xóa các key bắt đầu bằng prefix cộng:

• _X_CLOSED_;
• _PLOW_CLOSED_;
• _PLOW_STAGE_;
• _FSM_.

Prefix matching thuận tiện, nhưng cần delimiter và identity ổn định. Nếu prefix của instance này là tiền tố của instance khác, có thể xóa nhầm. Ví dụ Magic 611 và 6111 sẽ an toàn hơn nếu có separator rõ sau Magic.

Ngoài ra, reset là chuỗi nhiều mutation in-memory rồi save. Nếu process chết trước save, disk còn state cũ; nếu save giữa workflow, disk có state nửa mới. Nên ghi cluster status RESETTING trước, hoàn tất broker action rồi commit state new cycle trong một transaction.

Với schema object, reset có thể thay toàn bộ object cycle thay vì tìm key chuỗi. Archive cycle cũ giúp audit và giảm xóa wildcard.

12. Schema version và migration

Khi code phát triển, key hoặc ý nghĩa value thay đổi. Không có schema_version, bot không biết file được tạo bởi phiên bản nào.

Một migration an toàn:

1. đọc JSON raw;
2. validate checksum/syntax;
3. đọc schema version;
4. backup file;
5. chuyển từng version theo hàm deterministic;
6. validate invariant;
7. atomic write version mới;
8. log migration ID.

Ví dụ v1 dùng _PLOW_STAGE_4 chung Buy/Sell; v2 tách _PLOW_STAGE_4_B và _S. Không thể tự suy ra hai stage chỉ từ một số nếu cả hai position tồn tại. Migration phải đánh dấu ambiguous và yêu cầu reconcile, không bịa dữ liệu.

Rollback code cũng cần cân nhắc. Phiên bản cũ có thể không đọc schema mới. Deployment nên kiểm tra compatibility trước khi start bot.

13. Validation khi load

json.loads thành công không có nghĩa state hợp lệ. Cần validate:

• root object đúng kiểu;
• schema version hỗ trợ;
• login/server/symbol khớp môi trường;
• Magic hợp lệ và không trùng;
• P0 > 0, hữu hạn;
• Step/counter là integer trong range;
• stage chỉ 0–3;
• timestamp không quá vô lý;
• status thuộc enum;
• không có NaN/Infinity;
• cycle ID tồn tại;
• revision/checksum hợp lệ.

Nếu một key lỗi, không nên mặc định bỏ toàn bộ state mà không cảnh báo. Có thể phân loại:

• lỗi non-critical dashboard counter: repair và log;
• lỗi critical P0/LOCKED/stage: dừng strategy;
• identity mismatch: từ chối load;
• schema không hỗ trợ: yêu cầu migration.

Pydantic, dataclass validation hoặc JSON Schema đều có thể dùng. Quan trọng là chính sách lỗi.

14. Bảo mật và vận hành file state

GVStore hiện không chứa API password, nhưng file vẫn tiết lộ login, symbol, chiến thuật và trạng thái position. Cần:

• phân quyền chỉ user chạy bot được đọc/ghi;
• không commit .gv.json lên Git;
• không đặt trong thư mục đồng bộ công khai;
• backup mã hóa nếu có thông tin nhạy cảm;
• log không in credential;
• đường dẫn --gv phải được validate;
• tránh path traversal nếu path đến từ input không tin cậy.

File state không nên dùng như kênh điều khiển tùy tiện. Nếu dashboard hoặc web API sửa trực tiếp JSON trong lúc bot chạy, race và injection state có thể xảy ra. Mọi thay đổi phải qua command interface có auth, validation và audit.

15. JSON, SQLite hay Redis?

JSON phù hợp khi

• một process;
• state nhỏ;
• tần suất thay đổi thấp;
• cần dễ đọc và backup;
• demo/đào tạo;
• chấp nhận bổ sung atomic write và lock.

SQLite phù hợp khi

• cần transaction local;
• nhiều bảng/journal;
• query history;
• một host;
• muốn WAL và constraint;
• state phức tạp hơn key-float.

Redis phù hợp khi

• nhiều process/host;
• cần atomic operation, TTL, pub/sub;
• đã có hạ tầng vận hành;
• chấp nhận phụ thuộc network và persistence config.

Database server phù hợp khi

• nhiều strategy/account;
• audit dài hạn;
• dashboard và service cùng truy cập;
• cần quyền, backup và high availability.

Không chọn công nghệ chỉ vì “production”. JSON atomic với single writer có thể đủ cho bot cá nhân. Redis cấu hình sai persistence có thể kém an toàn hơn SQLite. Yêu cầu quyết định công cụ.

16. Event sourcing cho state giao dịch

Thay vì chỉ lưu snapshot cuối, bot ghi event append-only:

CYCLE_STARTED
ORDER_REQUESTED
ORDER_CONFIRMED
PLOW_STAGE_CHANGED
POSITION_CLOSED
LOCKDOWN_TRIGGERED
CLUSTER_RESET_COMPLETED

State hiện tại được reduce từ events; snapshot giúp khởi động nhanh. Ưu điểm:

• audit đầy đủ;
• biết state thay đổi vì sao;
• replay để debug;
• idempotency theo event ID;
• dễ so sánh với broker events.

Nhược điểm:

• schema event và migration phức tạp;
• cần xử lý duplicate/order;
• journal cũng phải durable;
• replay không thay thế reconcile broker.

Với khóa học, GVStore key-value giúp hiểu nền tảng. Khi hệ thống trưởng thành, event journal là bước nâng cấp tự nhiên.

17. Kiểm thử GVStore cơ bản

Round-trip

Set P0, stage, locked; save; tạo instance mới; load và so sánh. Kiểm tra Unicode trong prefix.

Delete

Xóa key, save, reload; key không tồn tại.

Default

Get key thiếu trả default đúng và không tự tạo key.

File không tồn tại

Load state rỗng hợp lệ, nhưng phải phân biệt lần khởi tạo đầu tiên qua metadata.

JSON hỏng

Hệ thống phải báo critical và không mở giao dịch. Test file rỗng, truncated, sai encoding, value không phải số.

Permission denied

Save thất bại phải lan lỗi hoặc chuyển safe mode; không được bỏ qua.

Atomic crash

Giả lập process chết trước/giữa/sau replace. File chính phải là version cũ hoặc mới hoàn chỉnh, không truncated.

18. Kiểm thử concurrency và recovery

Hai writer

Khởi chạy hai process test cùng path. Hệ thống phải từ chối process thứ hai hoặc phát hiện revision conflict. Không chấp nhận lost update im lặng.

Restart ở mỗi bước reset

Crash injection sau khi:

• ghi RESETTING;
• đóng một nửa positions;
• đóng hết nhưng chưa scan history;
• clear key nhưng chưa tạo cycle mới.

Sau restart, state machine phải tiếp tục đúng.

Broker/JSON mismatch

Tạo ma trận:

• state có/position có;
• state có/position không;
• state không/position có;
• ticket khác;
• cycle khác;
• symbol suffix khác.

Kiểm tra policy và alert.

Clock thay đổi

StartTime dùng epoch. Mô phỏng clock local nhảy hoặc timezone khác. Nên dùng UTC và broker timestamps; watermark ticket giảm phụ thuộc clock.

19. Thiết kế StateRepository tách khỏi chiến thuật

Thay vì bot gọi gv.set() trực tiếp khắp nơi, có thể định nghĩa repository:

class StateRepository(Protocol):
    def load_cluster(self, identity) -> ClusterState: ...
    def commit(self, expected_revision, state) -> int: ...
    def append_event(self, event) -> None: ...
    def acquire_lease(self, identity) -> Lease: ...

Implementation có thể là JSON, SQLite hoặc Redis. Logic Nhi Quái V6 không phụ thuộc storage cụ thể. Repository chịu trách nhiệm:

• serialization;
• schema validation;
• atomicity;
• optimistic lock;
• backup;
• migration;
• metrics.

Đây là bước từ compatibility API get/set sang domain model. Không nhất thiết refactor một lần. Có thể bọc GVStore trước, gom key construction vào một chỗ, rồi chuyển dần.

20. State nào nên dựng lại, state nào phải lưu?

Không phải mọi thứ đều cần persistence.

Có thể dựng từ broker snapshot

• tổng Buy/Sell volume;
• floating P/L;
• số positions;
• ticket theo Step nếu comment đáng tin;
• gross/net exposure.

Cần lưu vì snapshot không đủ

• P0 nếu không suy ra chắc chắn;
• cycle StartTime/ID;
• high-water stage trailing;
• tầng đã chốt và cooldown;
• trạng thái reset/lock workflow;
• order intent đang chờ khi response mất;
• revision và migration.

Chỉ phục vụ quan sát

• last dashboard draw;
• cache đã dựng;
• metrics tạm có thể tính lại.

Phân loại giúp giảm file và tránh lưu cache stale như nguồn sự thật.

21. Checklist nâng cấp GVStore JSON

• namespace gồm server, login, symbol, strategy, Magic;
• một strategy chỉ có một writer;
• file path nằm ở data volume có quyền phù hợp;
• JSON có schema version, identity và revision;
• save bằng temp + fsync + atomic replace;
• có backup phiên trước;
• dirty flag giảm ghi thừa;
• critical transition flush đúng lúc;
• lỗi load không biến thành state rỗng im lặng;
• validate range và type;
• reconcile với MT5 khi startup/reconnect;
• stage gắn side, ticket và cycle;
• reset dùng workflow có trạng thái;
• metrics cho save latency/error/revision conflict;
• test crash và concurrency;
• .gv.json nằm trong .gitignore;
• có quy trình migration và rollback.

22. Bài học khi port MQL5 sang Python

Port API không chỉ là đổi cú pháp. GlobalVariableSet chạy trong môi trường terminal; write_text chạy qua filesystem và process Python. Dù cùng tạo persistence key-value, failure mode khác nhau.

Bài học thứ nhất là phải port semantics: phạm vi, event, concurrency, durability và recovery. Bài học thứ hai là Python mở ra type/model tốt hơn; không cần mãi giới hạn mọi thứ ở float chỉ vì nguồn MQ5. Bài học thứ ba là broker state và strategy state phải được reconcile thay vì tin một phía. Bài học thứ tư là lỗi storage là lỗi giao dịch, vì nó có thể đổi hành động.

PyNhiQuaiBot dùng GVStore như cầu nối rất hữu ích để người học thấy mapping từ EA sang Python. Bước tiếp theo không phải vứt bỏ JSON ngay, mà làm rõ invariant và nâng implementation theo yêu cầu vận hành.

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

Có thể mở file JSON để sửa tay không?

Không nên khi bot đang chạy. Sửa tay có thể tạo race, sai type hoặc state không khớp broker. Nếu cần công cụ quản trị, hãy tạo command có validation và audit.

JSON hỏng có nên tự reset?

Không với state giao dịch đang có positions. Tự reset có thể mở lại lệnh sai. Nên dừng action, backup file hỏng và reconcile.

Mỗi symbol có nên dùng file riêng?

Thường giúp cô lập lỗi và lock đơn giản hơn. Tuy nhiên identity trong file vẫn cần đầy đủ.

Có cần lưu mỗi tick?

Không nhất thiết. Chỉ save khi dirty, nhưng các transition quan trọng phải durable. Chọn tần suất theo recovery point objective.

SQLite có luôn tốt hơn JSON?

Không. SQLite cho transaction và constraint, nhưng code/schema vận hành phức tạp hơn. JSON atomic single-writer đủ cho phạm vi nhỏ.

MT5 GlobalVariables có hoàn toàn an toàn không?

Không. Chúng cũng phụ thuộc namespace, không có transaction nhiều key và có thể lệch positions. Terminal quản lý persistence nhưng strategy vẫn cần reconcile.

Kết luận

GVStore JSON của PyNhiQuaiBot thay thế bề mặt API của MT5 GlobalVariables bằng một dictionary float được lưu ra file. Cách làm giúp port logic Nhi Quái V6 nhanh và dễ đọc, nhưng không tự mang theo các đặc tính vận hành của terminal. Ghi không atomic, lỗi load thành state rỗng, nhiều writer và thiếu schema là những rủi ro cần xử lý.

Một Global State đáng tin phải có namespace mạnh, schema version, validation, single writer hoặc concurrency control, atomic persistence và startup reconciliation. Quan trọng nhất, lỗi state phải khiến bot fail-safe chứ không tiếp tục mở lệnh với bộ nhớ trắng.

Nếu bạn muốn học cách thiết kế Global State, adapter MT5, FSM và cơ chế recovery cho Python Bot Auto Trading, hãy tham khảo chương trình Lập trình Python nâng cao Hedging tự động hóa của Hướng Nghiệp Dữ Liệu. PyNhiQuaiBot được dùng như dự án kỹ thuật để thực hành; khóa học không cam kết lợi nhuận và không thay thế đánh giá rủi ro cá nhân.

---

📌 Khóa Lập trình Python nâng cao Hedging (PyNhiQuaiBot)
Xem lộ trình & đăng ký · Zalo 0934.145.100 · Hướng Nghiệp Dữ Liệu