MT5 Manager API 服务与实时风控监控

问题

一家运营中的自营交易公司（prop firm），必须对每个交易者的账户执行亏损限额。它的平台原本通过 MetaTrader 5 的 HTTP Web API 读取交易数据。一次持仓查询可能要好几秒，违规检查由后端定时任务执行，所以交易者可能在超限之后还继续交易好几分钟。对自营交易公司来说，这就是实实在在的钱。

难点在哪里

• 原生的 MT5 Manager API 是一套 Windows SDK，有自己的连接生命周期和本地推送缓存（pump）。它很快，但它不是线程安全的。
• 风控引擎会根据读到的数据采取行动：禁止交易，判定账户失败。一个错的数字比一个慢的数字更糟。
• 规则因账户类型和阶段而不同，而监控和后端对“账户是否失败”绝不能得出不同结论。
• 这次改动必须在一个正在运行、有真实交易者的平台上发布，模拟盘和实盘还是分开的服务器。

架构

1. 01用 C#/.NET 7 基于原生 Manager API 构建 MetaTrader 5 集成服务：账户、持仓、成交、订单与每日历史接口，批量读取和交易权限控制；通过 API Key 与 IP 白名单保护，以独立的模拟盘和实盘 Windows 服务运行。
2. 02把持仓读取从耗时数秒的网络请求，改为读取 Manager API 的本地推送缓存。
3. 03设计实时违规监控：每隔几秒，依据后端发布到 Redis 的规则快照，检查每个活跃账户的日亏损、最大亏损和即时账户规则，并通过幂等的后端回调判定违规账户失败。
4. 04构建端到端营销归因：在官网和哈希路由的交易者 App 中采集首次触达的 UTM 与点击 ID，活动短链接，点击 → 注册 → 试用 → 购买的漏斗，以及同期群留存报表。
5. 05用 React 19、TypeScript 与 React Query 重建管理后台：KYC 审核、带安全校验的 MT5 账户操作（手动通过/失败、冻结、一键平仓）、联盟报表和促销向导。
6. 06新增登录 IP 与地理位置历史及重复 IP 风险标记，用于反欺诈审核；为 MT5 服务加入健康监控、告警邮件、崩溃通知和自动重连。

决策与挑战

• 从本地推送缓存读取，保留网络请求作为后备

  持仓读取从耗时数秒的网络请求，改为读取 Manager API 持续更新的本地副本。较慢的请求方式保留下来，用于缓存还没准备好的少数时刻。

• 串行化每一次 SDK 调用

  并发负载下，部分账户读到了别的账户的数据。我查到原因是 SDK 不是线程安全的，于是把所有调用放到同一把锁后面，连接和关闭也加了锁，并加了一道校验：返回的登录号必须就是请求的登录号。批量读取因此变慢，但为了读得正确，这个代价可以接受。

• 数字对不上就不动手

  数据看起来不对时，监控会跳过这个账户，而不是判定它失败。任何账户要晋级，它的净值都必须在两个独立的 MT5 数据源上一致。

• 失败流程要幂等，出错要报出来

  违规通过一个可以安全重复调用的回调上报。如果 MT5 拒绝权限变更，失败流程会直接抛错，数据库和 MT5 就不会悄悄地不一致。这也堵住了一个 bug：权限位掩码被取反，导致已判定失败的账户还能继续交易。

• 失败判定只算一处

  这套计算只放在一个共享服务里。隔夜利息被重复计算造成的误判失败，以及没有日限额的即时账户被误判失败，都就此结束。

• 部署时先关掉监控

  部署手册的步骤是：停掉两个服务，部署，在监控关闭的状态下手动验证一个已知违规的账户和一个已知正常的账户，最后才打开监控。

值得一讲的故事

经过验证的结果

• ✓持仓读取从耗时数秒的网络请求改为读取本地推送缓存。
• ✓每个活跃账户大约每 5 秒按亏损规则检查一次，以前这类检查由定时任务执行。
• ✓净值在两个独立的 MT5 数据源上一致之前，任何账户都不会晋级。
• ✓账户之间数据串读的事故已查明原因，并加了防护。
• ✓已在生产环境运行，模拟盘和实盘是两个独立的服务。

数字

• 6 个月约 250 次提交
• 5 个代码仓库
• 约每 5 秒一次违规检查
• 晋级前比对 2 个净值来源