2026年7月23日 · 戈策数据 · 技术理念
核心指标：200只股票实时扫描仅需1.3秒 · TCP直连通达信服务器 · 三源冗余自动切换 · 97%的请求在100ms内完成 · 近7个月零故障运行
戈策数据的行情接入层采用三源并行 + 三级缓存的架构设计。所谓「三源并行」是指同时接入pytdx通达信协议、Tushare Pro和AKShare三个独立的行情数据源；「三级缓存」则是在应用层、数据源层和持久层分别设置缓存策略，确保数据的实时性和高可用性。
这套架构从2026年初上线至今，持续优化了三个大版本。截止7月的数据，行情模块连续运行超过200天，日常请求成功率保持在99.7%以上。
架构设计原则：
pytdx是戈策数据行情体系的核心引擎。它通过TCP直连通达信行情服务器（180.153.18.170:7709），完全绕过HTTP代理和第三方API中转，实现了0.1秒建立连接、批量单次查询80只股票的性能指标。
相较于HTTP方式，TCP直连带来的优势很明显：
| 对比维度 | pytdx TCP直连 | HTTP API |
|---|---|---|
| 连接建立时间 | ≈100ms | 200-500ms（含TLS握手） |
| 单次查询上限 | 80只/批次 | 通常1只/请求 |
| 批量200只耗时 | ≈1.3s（3批次并发） | 5-30s（受限于限频） |
| 稳定性 | TCP长连接保活 | 依赖HTTP链路状态 |
| 故障模式 | 断线自动重连（≤3次） | 超时返回错误 |
在实际运行中，pytdx的连接成功率约98.5%。当遇到网络抖动或服务器端调整时，系统自动触发重试机制（最多2次），超过阈值则立即切换到备用数据源。
单一数据源在任何生产系统中都是风险敞口。戈策数据采用三源冗余 + 按优先级自动切换的策略：
| 数据源 | 协议类型 | 核心用途 | 缓存策略 |
|---|---|---|---|
| pytdx（通达信） | TCP直连 | 实时行情、成交额排序、Level-1快照 | 无状态，实时拉取 |
| Tushare Pro | HTTP API | 资金流向、龙虎榜、涨跌停数据 | 3600s缓存（1次/小时） |
| AKShare | HTTP API | 龙虎榜备选、K线备选、市场概况 | 3600s缓存 |
以「做T筛选」模块为例，完整的请求链路是这样的：
数据真实性铁律：当所有数据源都不可用时，系统不会返回模拟数据或缓存过期数据欺骗用户。用户看到的将是一个明确的「数据源不可用，请稍后重试」提示。这是戈策数据的核心原则——宁可功能暂停，绝不弄虚作假。
实时行情系统面临的核心矛盾是「快」与「准」的平衡——太频繁的请求会被数据源限频甚至封禁，太宽松的缓存又会导致数据时效性不足。戈策数据通过三级缓存解决了这个问题：
基于Python字典的轻量级缓存，用于存储单次请求周期内的中间计算结果。生命周期极短（通常几十毫秒），随请求结束自动销毁。主要用途：避免同一个批次内重复请求相同数据。
股票名称映射表（~8659只股票）在服务启动时加载到内存，后续毫秒级查询。Tushare Pro和AKShare的请求结果缓存时间为3600秒（1小时），避免频繁调用触发API限频。缓存文件持久化存储在/opt/aisaas/data/目录下，服务重启不丢失。
历史K线、财务数据等低频变动数据写入PostgreSQL数据库，通过INSERT ... ON CONFLICT DO UPDATE的upsert策略增量更新，避免全量覆盖。每日盘后自动执行复盘数据归档。
戈策数据整个行情系统运行在腾讯云轻量应用服务器上（4核4GB内存，60GB SSD），通过Supervisor守护进程管理。部署架构如下：
运维层面，核心指标有：
| 指标 | 当前值 | 目标值 |
|---|---|---|
| pytdx连接成功率 | 98.5% | ≥99% |
| HTTP数据源可用率 | 99.7% | ≥99.5% |
| 200只股票全量扫描时间 | 1.3s | ≤2.0s |
| 服务连续运行时间 | 200+天 | 无重启 |
| 数据降级通知延迟 | <500ms | ≤1s |
值得一提的是，从年初上线至今，系统仅经历过3次计划内重启（均与服务器系统更新有关），没有出现过非计划停机。pytdx连接在7月初的一周曾经出现连续超时（成功率降至95%），系统自动切换到Tushare Pro+AKShare双备运行，用户在3天内没有感知到任何异常。
行情系统的搭建过程远非一帆风顺。以下是在过去几个月中解决的关键问题：
初期手动修改了Nginx配置文件，但只要从宝塔面板重新应用配置，手改内容就被覆盖。解决方案：所有Nginx改动都走宝塔面板的「配置修改」入口，不再直接编辑/www/server/nginx/conf/目录下的配置文件。
Supervisor配置中command如果指向系统Python解释器，虚拟环境中的包就无法导入。解决方案：command必须指向虚拟环境内的可执行文件（/opt/aisaas/venv/bin/python），而非系统级Python。
在Windows本地编写代码后通过SSH推送到Linux服务器，中文注释和字符串经常出现编码问题。解决方案：采用base64编码后通过SSH管道传输，避免中间编码转换环节。
pytdx查询时需要区分市场代码（深圳=0，上海=1），初期未正确区分导致大量股票的行情数据读取错误。解决方案：建立完整的股票代码→市场代码映射表，并在代码中添加校验逻辑。
相比早期版本，7月的架构优化主要体现在以下方面：
7月升级亮点清单：
ThreadPoolExecutor并行查询，200只股票耗时从2.5s降至1.3sA：商业行情中间件（如Wind、Choice）年费数万，和戈策数据的免费定位不符。开源方案中pytdx是最成熟、社区活跃度最高的通达信协议实现，且完全满足A股行情的实时需求。
A：会的。pytdx取的是实时快照数据，Tushare取的是统计处理后数据，两者在数值上可能有毫秒级差异。戈策数据的策略是：以pytdx数据作为实时决策的基准，Tushare/AKShare数据用于补充非实时维度（如龙虎榜、资金流向），两部分互不覆盖，在每个分析报告中标注数据来源。
A：极端行情下所有数据源都会面临压力。pytdx通达信服务器在流动性枯竭时快照推送频率下降，但这属于数据源侧问题。系统本身在2026年2月的千股跌停日中经受了考验——虽然扫描耗时从1.3s增加到约2.8s，但服务没有宕机，所有分析报告正常输出。
A：当前配置满足日常使用。CPU峰值出现在早盘集合竞价时段（约9:20-9:30），瞬时负载可达70%以上，但均在可控范围内。如果用户量和请求频率持续增长，下一步优化方向是升级到8C16G配置并对计算密集型任务做异步化改造。