Bot hedging thường không hỏng ở công thức chỉ báo mà hỏng ở “biến rải rác”: mỗi hàm giữ một flag, mỗi thread có một bản sao vị thế, dashboard hiển thị dữ liệu cũ, còn execution lại dựa vào response chưa được đối soát. Khi API reconnect, bot không biết lệnh nào đã khớp, campaign đang Surplus hay Hedge, và level nào được phép mở tiếp. Đó là lý do kiến trúc global state pandas bot trading phải được xây trước logic đặt lệnh.

Global State không có nghĩa đặt mọi biến vào một dictionary toàn cục rồi cho tất cả module cùng sửa. Cách đó chỉ chuyển sự hỗn loạn về một nơi. State đúng là nguồn sự thật có schema, quyền cập nhật, phiên bản, timestamp và quy trình phục hồi. Pandas/NumPy đúng là công cụ phân tích snapshot và lịch sử; chúng không phải cái cớ để nhiều thread sửa chung một DataFrame.

Bài viết trình bày cách thiết kế state cho bot nhiều vị thế, cách dùng Pandas/NumPy đúng vai trò, cách chuẩn hóa API Binance · Bitget · MT5 API · SSI · DNSE, cùng các lỗi race condition, stale cache và look-ahead thường gặp. Nội dung phục vụ giáo dục kỹ thuật, không cam kết lợi nhuận và không thay thế đánh giá rủi ro trước khi dùng vốn.

Global State là gì trong một bot trading?

Global State là mô hình nhất quán về những gì hệ thống tin đang xảy ra tại một thời điểm. Nó thường gồm account, market snapshot, order, fill, position, campaign, FSM state, risk metrics và sức khỏe dịch vụ. Từ “global” nói về phạm vi thông tin, không bắt buộc cách triển khai bằng biến module.

Một quyết định mở Hedge phải đọc cùng một snapshot: vị thế đã xác nhận, pending order, equity, margin, giá, timestamp và Guard status. Nếu quantity lấy từ snapshot lúc 10:00:00 nhưng equity lấy lúc 09:59:50, bot đang kết hợp hai thế giới khác nhau. Phiên bản snapshot giúp phát hiện vấn đề này.

State có ba lớp thời gian:

1. Observed state: dữ liệu vừa quan sát từ sàn hoặc feed.
2. Confirmed state: dữ liệu đã chuẩn hóa, kiểm tra và chấp nhận làm nguồn quyết định.
3. Desired state: trạng thái mà strategy muốn đạt, biểu diễn qua intent.

Không được biến desired thành confirmed ngay sau khi gửi request. Order có thể bị reject, partial fill hoặc timeout. Chỉ reconciler, dựa trên dữ liệu chính thức, mới xác nhận thay đổi vị thế.

State khác cache thế nào?

Cache lưu dữ liệu để giảm latency hoặc số lần gọi nguồn. Cache có TTL và có thể hết hạn. State chứa quan hệ nghiệp vụ và bất biến. Giá mới nhất có thể nằm trong cache; việc campaign đang HEDGE_BUILD và order nào thuộc campaign phải nằm trong state có kiểm soát.

Một số dữ liệu vừa được cache vừa tham gia state. Khi đó cần metadata as_of, source, version, is_stale. Bot không nên dùng giá chỉ vì biến còn tồn tại. Guard phải kiểm tra tuổi dữ liệu so với ngưỡng của chiến lược.

Schema tối thiểu cho bot Hedging đa vị thế

Schema tốt làm quy tắc rõ trước khi code. Bảng position nội bộ không chỉ cần symbol, side và quantity. Nó cần exchange, account, instrument id, position mode, campaign id, role, level, entry, realized/unrealized P/L, timestamp và version.

Nhóm	Trường gợi ý	Lý do
Định danh	exchange, account_id, symbol, instrument_id	Tránh trộn tài khoản/sản phẩm
Nghiệp vụ	campaign_id, role, x_level, strategy_id	Phân biệt Surplus, Hedge và chiến dịch
Khối lượng	quantity, contract_multiplier, notional	Quy đổi exposure đúng
Giá trị	entry_price, mark_price, pnl, fee	Tính rủi ro sau chi phí
Trạng thái	status, fsm_state, pending_action	Chống hành động không hợp lệ
Thời gian	event_time, received_at, as_of	Phát hiện trễ và sai thứ tự
Kiểm soát	version, source, correlation_id	Audit và optimistic concurrency

Order và fill phải là hai entity khác nhau. Một order có thể sinh nhiều fill; position là kết quả tổng hợp sau fill và quy tắc sản phẩm. Nếu lưu mọi thứ trong một bảng “trades”, bot dễ cộng sai hoặc tưởng order NEW đã trở thành position.

Magic, comment và client order id

MT5 thường có magic/comment; sàn crypto có client order id; API chứng khoán có mã lệnh riêng. Adapter nên ánh xạ về một client_order_id nội bộ có cấu trúc hoặc UUID. Metadata campaign, role và level được lưu bền vững, không phụ thuộc hoàn toàn vào comment bị giới hạn ký tự.

Idempotency key phải ổn định cho cùng một ý định. Nếu request timeout, execution tra cứu bằng key trước khi retry. Tạo key mới mỗi lần lặp sẽ vô hiệu cơ chế chống trùng.

Kiểu dữ liệu và precision

Không nên dùng float tùy tiện cho quantity cần làm tròn chính xác. Market rules quy định tick size, step size, minimum notional và số chữ số. Adapter chịu trách nhiệm lượng tử hóa theo quy tắc sàn. Trong phân tích, NumPy float có thể đủ; tại biên gửi lệnh, cần quy tắc Decimal hoặc integer ticks rõ.

Timestamp nên thống nhất UTC và lưu cả event time lẫn received time. Sự chênh lệch giúp đo latency. Không dùng giờ hệ điều hành chưa đồng bộ để sắp event tài chính.

Thiết kế state store thay cho biến toàn cục

Một state store tối thiểu cung cấp thao tác lấy snapshot bất biến, áp event, kiểm tra version và lưu checkpoint. Module strategy chỉ đọc snapshot. Execution tạo command. Reconciler là nơi áp dữ liệu xác nhận. Dashboard cũng chỉ đọc.

from dataclasses import dataclass
from datetime import datetime
from typing import Tuple

@dataclass(frozen=True)
class Position:
    symbol: str
    side: str
    quantity: float
    campaign_id: str
    role: str
    level: int

@dataclass(frozen=True)
class BotSnapshot:
    version: int
    as_of: datetime
    positions: Tuple[Position, ...]
    fsm_state: str
    equity: float
    margin_used: float

frozen=True không giải quyết mọi concurrency nhưng ngăn sửa vô tình. Khi có fill mới, store tạo snapshot version mới thay vì sửa object mà strategy đang đọc. Với dữ liệu lớn, có thể dùng structural sharing hoặc lưu bảng riêng; nguyên tắc vẫn là một chu kỳ quyết định thấy một phiên bản.

Optimistic concurrency

Strategy đọc version 120 và tạo intent. Trước lúc execution gửi, state đã lên 121 do một fill khác. Execution kiểm tra precondition: intent còn hợp lệ trên 121 hay phải tính lại. Đây là optimistic concurrency; nó tránh khóa dài nhưng yêu cầu xử lý conflict.

Pessimistic lock có thể dùng ở đoạn ngắn như cập nhật mapping, nhưng không nên giữ lock trong lúc gọi API mạng. Request có thể chậm vài giây và chặn cả bot. Hãy ghi trạng thái pending nguyên tử, nhả lock, gọi API, sau đó áp kết quả qua event.

Event log và checkpoint

Snapshot cho biết hiện tại; event log cho biết vì sao. Mỗi event nên có type, payload, event time, received time, correlation id, causation id và version. Khi điều tra lệnh trùng, bạn cần nối signal → intent → command → request → response → fill → reconciliation.

Không nhất thiết triển khai event sourcing đầy đủ ngay. Một bảng audit append-only kết hợp checkpoint đã tạo giá trị lớn. Cần quy định retention, che secret và tránh ghi payload chứa API key.

Pandas nên đảm nhiệm phần nào?

Pandas mạnh ở dữ liệu dạng bảng: chuẩn hóa lịch sử, nhóm vị thế, tính P/L theo campaign, resample nến, tạo báo cáo và chuẩn bị backtest. Nó giúp code biểu đạt phép biến đổi rõ hơn vòng lặp thủ công, nhưng DataFrame không tự bảo đảm dữ liệu đúng.

Ví dụ, để tổng hợp gross và net theo symbol:

import numpy as np
import pandas as pd

positions = pd.DataFrame(
    {
        "symbol": ["BTCUSDT", "BTCUSDT", "ETHUSDT"],
        "side": ["LONG", "SHORT", "LONG"],
        "quantity": [2.0, 1.25, 5.0],
        "mark_price": [60_000.0, 60_000.0, 3_000.0],
    }
)

positions["signed_qty"] = np.where(
    positions["side"].eq("LONG"),
    positions["quantity"],
    -positions["quantity"],
)
positions["notional"] = positions["quantity"] * positions["mark_price"]

summary = positions.groupby("symbol").agg(
    net_qty=("signed_qty", "sum"),
    gross_notional=("notional", "sum"),
)

Trong production, cần contract multiplier, currency conversion và validation. Đoạn trên minh họa cách vector hóa, không phải công thức chung cho mọi sàn.

DataFrame snapshot, không phải state mutable chung

Một anti-pattern là GLOBAL_DF được websocket append, strategy filter, dashboard sort và execution sửa status cùng lúc. Pandas không cung cấp transaction cho mô hình này. View/copy cũng dễ gây hành vi khó đoán.

Thay vào đó, reconciler tạo snapshot dữ liệu bất biến hoặc publish reference mới. Consumer giữ bản của mình trong một chu kỳ. Nếu dashboard cần sort, nó sort bản copy. Nếu lịch sử lớn, ghi theo batch vào Parquet/database rồi query riêng.

Validation trước khi phân tích

Trước groupby, hãy kiểm tra schema, null, duplicate key, quantity âm, side lạ, timestamp không đơn điệu và currency thiếu. Có thể dùng assert, dataclass validation hoặc thư viện schema. Dữ liệu bẩn được vector hóa chỉ tạo kết quả sai nhanh hơn.

Nên đặt invariant như: mỗi fill_id duy nhất trong exchange/account; quantity > 0; side thuộc enum; event time không ở tương lai quá ngưỡng; role thuộc SURPLUS/HEDGE; campaign id không rỗng với lệnh chiến lược.

NumPy và vector hóa cho backtest

NumPy phù hợp với mảng giá, return, distance, mask và mô phỏng nhiều tham số. Vector hóa loại bỏ overhead vòng lặp Python trong phép tính độc lập. Tuy nhiên, FSM có phụ thuộc tuần tự không phải lúc nào cũng vector hóa hoàn toàn được.

Ta có thể vector hóa feature như ATR, khoảng cách tới anchor và điều kiện chạm level, sau đó chạy event loop chỉ trên những điểm ứng viên. Cách hybrid thường nhanh và dễ kiểm chứng hơn việc cố nhét toàn bộ state machine vào các phép shift phức tạp.

Tránh look-ahead bias

Pandas khiến việc dùng dữ liệu tương lai vô tình rất dễ. shift(-1), centered rolling, fill ngược hoặc merge không đúng timestamp có thể đưa giá tương lai vào feature. Mỗi feature cần available_at, không chỉ event_time.

Ví dụ báo cáo doanh nghiệp có ngày kỳ nhưng công bố sau đó; dữ liệu thị trường từ hai sàn có latency khác. Backtest phải quyết định dựa trên thông tin thực sự có tại thời điểm đó.

Dtype và bộ nhớ

Một triệu dòng với nhiều cột object tốn bộ nhớ lớn. Hãy dùng category cho enum, integer/float width phù hợp, datetime chuẩn, đọc theo cột cần thiết và lưu Parquet. Nhưng không hạ precision tiền tệ mà không đo sai số.

Tối ưu bắt đầu bằng profiling. Nếu nút thắt là API hoặc groupby, tăng thread không giúp. Nếu FSM loop chậm, có thể precompute feature hoặc dùng NumPy/Numba sau khi có test đối chiếu.

Cache market data và account data

Không nên gọi REST mỗi mili-giây. Market websocket cung cấp dòng sự kiện, cache giữ latest tick/orderbook với timestamp. REST được dùng cho bootstrap, đối soát định kỳ hoặc phục hồi. Account websocket cung cấp order/fill nhưng vẫn cần snapshot chính thức sau reconnect.

TTL phải theo loại dữ liệu:

Dữ liệu	Đặc tính TTL	Hành vi khi stale
Tick/mark price	Rất ngắn, tùy chiến lược	Chặn mở mới
Market rules	Dài, refresh theo phiên bản	Không gửi nếu thiếu
Position	Event-driven + reconcile	Chuyển Recovery nếu lệch
Balance/equity	Ngắn	Guard dùng giá trị bảo thủ
Instrument metadata	Theo ngày/sự kiện	Reload trước phiên

Không có một TTL chung. Dữ liệu stale không nhất thiết xóa; cần giữ giá trị và đánh dấu để điều tra. Strategy không được coi stale value là fresh chỉ vì key tồn tại.

Cache stampede và rate limit

Khi cache hết hạn, nhiều worker có thể cùng gọi API. Dùng single-flight: một worker refresh, các worker khác chờ hoặc dùng dữ liệu cũ trong giới hạn. Rate limiter nên dùng chung theo API key và endpoint weight, không đặt riêng trong mỗi thread.

Khi sàn trả 429, bot không retry dồn dập. Backoff có jitter, circuit breaker và ưu tiên request giảm rủi ro. Guard có thể cấm mở mới trong thời gian degraded.

Orderbook không phải chỉ giá bid/ask

Nếu sizing lớn, cần depth và slippage estimate. Snapshot orderbook phải được ghép đúng sequence với delta; mất sequence yêu cầu tải lại. Một orderbook sai có thể làm Guard đánh giá thanh khoản quá lạc quan.

Với chiến lược không cần microstructure, đừng lưu mọi tick vô hạn trong RAM. Downsample hoặc ghi bất đồng bộ. State vận hành chỉ giữ cửa sổ cần thiết.

Chuẩn hóa API đa sàn

Binance, Bitget, MT5 API, SSI và DNSE có vocabulary khác nhau. Adapter chuyển chúng về domain model chung nhưng không được che giấu capability khác biệt. Interface nên cho phép hỏi sàn có hỗ trợ hedge mode, reduce-only, client id, partial cancel hoặc streaming nào.

Một domain order có thể gồm:

exchange, account, instrument, side, position_effect,
order_type, quantity, price, time_in_force,
client_order_id, campaign_id, role, level

Adapter ánh xạ và từ chối sớm nếu capability không hỗ trợ. Không âm thầm bỏ reduce_only hoặc đổi order type, vì điều đó có thể tăng rủi ro trái ý định.

Binance và Bitget

Cần phân biệt spot/futures, one-way/hedge mode, position side, reduce-only, funding, precision và rate-limit weight. Account mode là một phần state cấu hình; bot phải xác minh lúc bootstrap.

MT5 API

Tài khoản có thể theo netting hoặc hedging tùy broker. Ticket, position, deal và order là khái niệm khác nhau. Magic/comment hỗ trợ phân loại nhưng không thay database mapping. Terminal connection và timezone cũng cần heartbeat.

SSI và DNSE

Thị trường chứng khoán có phiên, ngày giao dịch, loại lệnh, bước giá và quy tắc riêng. Adapter cần calendar và session state. Không áp vòng lặp 24/7 của crypto. Quyền API và tính năng thực tế phải kiểm tra theo tài khoản, tài liệu hiện hành.

Đọc thêm bài kết nối đa sàn Binance–SSI/DNSE. Mục tiêu adapter là cô lập khác biệt, không giả vờ khác biệt không tồn tại.

Concurrency: thread, asyncio và hàng đợi

Bot có nhiều công việc: nhận market data, nhận account event, tính strategy, gửi lệnh, ghi log và cập nhật dashboard. Có thể dùng thread, asyncio hoặc process. Lựa chọn phụ thuộc thư viện và tải, nhưng quyền sửa state phải tập trung.

Một kiến trúc dễ kiểm soát:

Market adapters ─┐
Account adapters ├─> Event queue -> Reconciler -> State Store
Timers ----------┘                         |
                                            v
Strategy <- immutable snapshot -> Intent -> Guard -> Execution queue

Chỉ execution worker gửi lệnh cho một account/symbol theo policy. Strategy có thể chạy song song trên snapshot nhưng không gọi adapter trực tiếp. Event queue tạo thứ tự xử lý và backpressure.

Race condition check-then-act

Hai worker cùng đọc “chưa có hedge”, cùng tạo order, rồi gửi hai hedge. Lock quanh câu kiểm tra local không đủ nếu request nằm ngoài lock hoặc có nhiều process. Cần pending intent được ghi nguyên tử và idempotency ở execution.

Version precondition giúp intent cũ bị từ chối. Unique constraint theo (campaign_id, role, level, active) cũng tạo hàng rào ở database. Không dựa vào timing sleep.

Backpressure

Nếu event đến nhanh hơn xử lý, queue tăng vô hạn và state trở nên cũ. Cần metric queue lag, coalescing cho tick không cần từng điểm, ưu tiên account event và chính sách drop rõ. Không được drop fill.

Khi lag vượt ngưỡng, Guard chặn mở mới. Tốc độ không chỉ là throughput; freshness mới quyết định an toàn.

Reconciliation và phục hồi sau reconnect

Reconnect là trạng thái bình thường, không phải ngoại lệ hiếm. Quy trình bootstrap nên:

1. Dừng strategy và đặt FSM vào BOOTSTRAP.
2. Xác minh account mode, market rules và clock.
3. Tải open orders, positions, recent fills, balance.
4. Chuẩn hóa qua adapter.
5. So sánh với checkpoint và event log.
6. Khôi phục mapping campaign/role/level.
7. Ghi discrepancy và xử lý theo policy.
8. Chỉ chuyển IDLE, HEDGED hoặc RECOVERY khi invariant đúng.

Timeout gửi order là tình huống nguy hiểm nhất. Không biết request thất bại hay response thất lạc. Execution phải tra client order id hoặc recent orders. Nếu vẫn không xác định, Lockdown thay vì gửi bản sao.

Sai lệch nào có thể tự sửa?

Một event websocket bị thiếu nhưng REST snapshot xác nhận fill có thể được bổ sung. Một position thủ công không có campaign id có thể được đánh dấu EXTERNAL và chặn strategy trên symbol. Không nên tự gán lệnh lạ vào campaign chỉ vì cùng side.

Policy phải phân loại discrepancy: expected delay, recoverable, requires operator, critical. Mọi sửa tự động có audit event.

Checkpoint không thay thế sàn

Checkpoint giúp phục hồi nhanh nhưng có thể cũ. Sau restart luôn đối soát với sàn. Nếu database nói không có position còn sàn nói có, vị thế sàn là rủi ro thật cần quản lý.

Global State kết nối với FSM, Guard và Sweep

FSM đọc state để quyết định transition. Guard đọc cùng snapshot để phủ quyết intent. Sweep tạo kế hoạch giảm position dựa trên role và liquidity. Nếu ba module dùng ba bản dữ liệu khác nhau, kiến trúc mất ý nghĩa.

Các trạng thái có thể gồm BOOTSTRAP, IDLE, SURPLUS_BUILD, HEDGE_BUILD, SWEEP, RECOVERY, LOCKDOWN. Transition tạo event; không trực tiếp sửa nhiều flag. Mỗi state quy định action nào được phép.

Guard nên kiểm tra:

• Snapshot age và market data age.
• State version so với intent.
• Gross/net exposure sau action.
• Equity, margin, drawdown.
• Pending order và duplicate role/level.
• Spread, slippage estimate, market session.
• Adapter health, queue lag và reconciliation status.

Sweep cần snapshot chính xác hơn mở lệnh vì thứ tự đóng thay đổi net exposure. Sau mỗi partial fill, nó chờ reconciliation và lập batch tiếp. Không giả định đóng nhiều chân là nguyên tử.

Để hiểu logic exposure, xem Hedge vs Martingale Python bot. Để nhìn toàn hệ thống, xem tổng quan PyNhiQuaiBot.

Dashboard và observability từ cùng một state

Dashboard không nên gọi từng sàn độc lập rồi hiển thị con số khác strategy. Nó đọc read model được tạo từ confirmed state. Mỗi widget có as_of và source. Nếu stale, giao diện phải hiển thị rõ thay vì giữ màu xanh.

Các metric quan trọng:

• State version, FSM state, campaign id.
• Heartbeat từng adapter và queue lag.
• Gross/net exposure, equity, margin, drawdown.
• Pending order, intent age, reconciliation discrepancy.
• Cache hit/miss, REST rate limit, websocket reconnect.
• P/L trước/sau fee, funding và slippage.

Log có cấu trúc tốt hơn câu text tự do. Dùng correlation id để nối một quyết định xuyên module. Không log secret hoặc full credential header.

Alert phải đến từ tiến trình ngoài bot hoặc dịch vụ giám sát. Nếu bot chết, chính nó không thể gửi cảnh báo. VPS cần process supervisor, log rotation, đồng bộ thời gian và disk alert.

Backtest dùng chung domain model với live trading

Backtest và live không nên là hai codebase chiến thuật khác nhau. Strategy nhận snapshot/domain event, adapter live hoặc simulator cung cấp dữ liệu. Execution simulator mô phỏng fill, phí và latency. Cách này giảm sai lệch logic.

Tuy nhiên, không cố dùng nguyên mọi infrastructure. Backtest cần tốc độ, live cần bất đồng bộ và phục hồi. Hãy chia sẻ domain model, strategy, Guard rule và test vector; cho phép storage/execution implementation khác.

Mô phỏng event order

OHLC không cho biết intrabar path. Grid có nhiều level nên thứ tự chạm quan trọng. Dùng tick dữ liệu nếu có, hoặc chạy kịch bản conservative/optimistic và báo khoảng kết quả. Không chọn thứ tự có lợi mặc định.

Partial fill, reject, latency và phí phải là event. Backtest chỉ tạo fill ngay tại trigger sẽ bỏ qua phần khó nhất của state machine.

Báo cáo chất lượng dữ liệu

Trước P/L, báo missing interval, duplicate timestamp, outlier, timezone, corporate action và số dòng bị loại. Kết quả không đáng tin nếu pipeline im lặng sửa dữ liệu.

Không có backtest nào cam kết lợi nhuận. Mục tiêu là bác bỏ giả định yếu, đo vùng rủi ro và chuẩn bị kịch bản.

Những hiểu lầm phổ biến

“Global State là anti-pattern nên phải tránh hoàn toàn.” Shared mutable global là anti-pattern; domain state tập trung với quyền cập nhật rõ lại là cần thiết. Bot vẫn cần một mô hình thống nhất về tài khoản.

“Dùng Redis là tự động giải quyết concurrency.” Redis cung cấp primitive, không thiết kế invariant. Hai worker vẫn có thể tạo intent trùng nếu key và transaction sai.

“Pandas chậm nên không dùng trong trading.” Pandas phù hợp analytics và backtest vừa/ lớn nếu dùng đúng dtype, vector hóa và batch. Không phù hợp làm transactional state đa thread.

“Websocket là real-time nên không cần REST.” Websocket có thể mất event. Snapshot REST và sequence/reconciliation vẫn cần.

“Order response thành công nghĩa position đã đúng.” Response có thể chỉ xác nhận accepted. Fill và position cần theo dõi riêng.

“Lock mọi thứ là an toàn.” Lock dài gây nghẽn và deadlock; lock local không bảo vệ multi-process. Cần state ownership, event queue, idempotency và version.

“Dashboard chỉ để nhìn lợi nhuận.” Dashboard vận hành cần freshness, discrepancy, Guard, latency và state. P/L không giải thích bot có khỏe hay không.

Ví dụ thực hành: vòng đời một lệnh Hedge

Giả sử confirmed snapshot version 501 có Long 10, Short 4, net +6. Strategy muốn net +3 nên tạo intent Short 3, role HEDGE, campaign C42, level 2, precondition version 501. Intent chưa làm thay đổi position.

Guard tính gross sau lệnh, margin dự kiến, spread, age dữ liệu và FSM. Nếu hợp lệ, execution ghi pending command với idempotency key C42-HEDGE-L2, rồi gửi adapter. API timeout. Execution không tạo key mới; nó query order bằng key.

Sàn trả order đã partial fill 2. Reconciler ghi fill, position thành Long 10/Short 6, version 502. Strategy cũ không được tiếp tục gửi 3 vì precondition đã cũ. Nó chạy lại và có thể đề xuất thêm 1. Nếu websocket nói fill 2 nhưng REST nói fill 2,5, discrepancy chuyển Recovery cho đến khi xác nhận.

Ví dụ này cho thấy phần khó không nằm ở SELL 3. Phần khó là giữ quan hệ giữa ý định, lệnh, fill, position và phiên bản qua timeout. Global State chính là nơi biểu diễn quan hệ đó.

Checklist triển khai Global State

Schema

• Tách order, fill, position, campaign và intent.
• Có exchange/account/instrument trong key.
• Có role Surplus/Hedge, X-Level và campaign id.
• Có event time, received time, source, version.
• Có precision/contract multiplier/currency.

Quyền cập nhật

• Strategy chỉ đọc snapshot và tạo intent.
• Execution không tự sửa confirmed position.
• Reconciler là đường cập nhật dữ liệu sàn.
• Dashboard chỉ đọc read model.
• Operator command được audit và đi qua Guard.

Concurrency

• Snapshot bất biến trong một decision cycle.
• Có idempotency key và unique constraint.
• Không giữ lock trong network call.
• Có queue lag/backpressure metric.
• Intent kiểm tra state version trước execution.

Phục hồi

• Bootstrap tải position/order/fill/balance.
• Timeout được query trước retry.
• Reconnect có sequence/snapshot policy.
• Discrepancy phân loại và ghi log.
• External position không bị tự gán vào campaign.

Pandas/NumPy

• Validate schema trước groupby.
• Tránh DataFrame mutable đa thread.
• Kiểm tra look-ahead và timestamp availability.
• Profile trước tối ưu; dùng dtype hợp lý.
• Backtest mô phỏng fee, partial fill và event order.

An toàn

• Guard có stale data, gross/net, margin, drawdown.
• Secret không nằm trong code; key không có quyền rút.
• Có Recovery/Lockdown và runbook.
• Alert độc lập với tiến trình bot.
• Chạy testnet/paper trước mọi cân nhắc vốn thật.

Ai nên học Global State, Pandas và bot hedging?

Chủ đề phù hợp với người đã biết Python cơ bản và từng gọi API, nhưng bot hiện có nhiều flag, khó restart hoặc không giải thích được lệnh trùng. Data analyst muốn chuyển từ notebook sang hệ thống chạy liên tục cũng cần học biên giữa DataFrame phân tích và state giao dịch.

Trader không cần trở thành chuyên gia distributed systems, nhưng cần hiểu source of truth, idempotency, reconciliation và risk budget. Đây là kiến thức bảo vệ tài khoản khỏi lỗi phần mềm độc lập với chất lượng tín hiệu.

Nếu bạn chỉ muốn copy một bot hoặc tìm cam kết sinh lời, chủ đề này không phù hợp. Xây state tốt không tạo alpha; nó làm hành vi đúng với thiết kế, đo được và dễ dừng khi sai.

Lộ trình PyNhiQuaiBot và Phần Infrastructure

Trong khóa Lập trình Python nâng cao Hedging tự động hóa, Infrastructure gồm Global State, Pandas/NumPy và API. Sau nền này, học viên đi vào Grid Logic với Step/X-Level, Surplus/Hedge, multithread; Brain với FSM, Sweep, Guard; rồi UX với dashboard, backtest và VPS.

Chương trình PyNhiQuaiBot · Hướng Nghiệp Dữ Liệu · GV Đặng Trí Thanh gồm 12 buổi học + 8 buổi bài tập + 5 buổi phụ đạo. Việc có bài tập và phụ đạo đặc biệt hữu ích cho state: học viên phải tự tạo lỗi reconnect, partial fill, stale cache, rồi đọc log để phục hồi.

Lớp khai giảng 15:00 Thứ Bảy ngày 01/08/2026, học Thứ Bảy + Chủ nhật. Học phí công bố 24.000.000 VNĐ. Xem yêu cầu đầu vào, đề cương và thông tin cập nhật tại course hub PyNhiQuaiBot.

Kiến thức khóa học hỗ trợ xây và kiểm thử hệ thống, không bảo đảm lợi nhuận. Mọi bot đều chịu rủi ro chiến lược, thị trường, thanh khoản, hạ tầng và con người.

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

1. Có nên dùng một dictionary global cho bot nhỏ?

Prototype có thể dùng, nhưng hãy bọc bằng class/store, định nghĩa schema và quyền cập nhật ngay từ đầu. Dictionary được nhiều module sửa tự do sẽ nhanh chóng tạo flag mâu thuẫn và khó test.

2. Pandas có thread-safe không?

Không nên giả định DataFrame mutable an toàn khi nhiều thread cùng đọc/ghi. Dùng snapshot/copy, single writer hoặc queue. Analytics có thể chạy trên bản riêng.

3. Redis hay database có cần thiết không?

Không bắt buộc cho bài học đầu. In-memory store có checkpoint đủ cho prototype. Khi cần multi-process, durability hoặc query, chọn công nghệ theo yêu cầu. Công nghệ không thay invariant.

4. Sàn và local state lệch nhau thì tin bên nào?

Position/order thực tế trên sàn là rủi ro thật nên phải ưu tiên đối soát. Local metadata giải thích campaign nhưng không được phủ nhận position sàn. Nếu không map được, chuyển Recovery và chặn mở mới.

5. NumPy có làm bot đặt lệnh nhanh hơn không?

NumPy tăng tốc phép tính mảng, không giảm network latency. Dùng cho feature/backtest và batch calculation. Đừng tối ưu trước khi profiling.

6. Làm sao chống lệnh trùng khi timeout?

Dùng client order id/idempotency key ổn định, ghi pending trước gửi, query sàn trước retry và có unique constraint theo campaign-role-level. sleep không phải giải pháp.

7. Có thể dùng cùng state schema cho năm sàn không?

Có domain schema chung, nhưng cần trường capability và adapter riêng. Không ép mọi sàn vào semantics không tồn tại. Binance, Bitget, MT5, SSI, DNSE vẫn cần test độc lập.

8. Nên đọc bài nào tiếp?

Đọc tổng quan PyNhiQuaiBot để thấy bốn phần, Hedge vs Martingale để hiểu exposure, sau đó Step/X-Level và FSM chống nhồi lệnh.

Kết luận: state đúng trước, chiến thuật sau

Một bot nhiều vị thế chỉ đáng tin khi có thể trả lời: dữ liệu đến từ đâu, cập nhật lúc nào, ai được sửa, vì sao một lệnh tồn tại, và phục hồi thế nào sau timeout. Global state pandas bot trading đúng nghĩa là sự kết hợp giữa domain state có kiểm soát với công cụ phân tích dữ liệu phù hợp, không phải một DataFrame khổng lồ dùng chung.

Nếu bạn muốn xây nền tảng này trong một dự án đầy đủ từ Infrastructure đến Grid Logic, Brain và UX, hãy xem Lập trình Python nâng cao Hedging tự động hóa — PyNhiQuaiBot. Khóa khai giảng 15:00 ngày 01/08/2026, học Thứ Bảy và Chủ nhật, gồm 12 buổi học + 8 buổi bài tập + 5 buổi phụ đạo, học phí 24.000.000 VNĐ.

CTA mạnh: Liên hệ GV Đặng Trí Thanh · Hướng Nghiệp Dữ Liệu qua Zalo 0934.145.100 để trao đổi nền tảng đầu vào, hoặc đăng ký tại trang khóa PyNhiQuaiBot. Hãy đầu tư vào khả năng thiết kế, kiểm chứng và kiểm soát rủi ro; không dựa vào lời hứa lợi nhuận.

---

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