19年创业做过一年的量化交易但没有成功，作为交易系统的开发人员积累了一些经验，最近想重新研究交易系统，一边整理一边写出来一些思考供大家参考，也希望跟做量化的朋友有更多的交流和合作。

接下来说说数据采集方式。

在自动化交易系统中，数据采集方式决定了系统对市场变化的反应速度、数据的准确性和延迟控制能力。不同的数据采集方式适用于不同类型的交易策略，根据实时性和数据完整性的需求，数据采集方式主要分为 REST API 轮询和 WebSocket 实时推送两大类。以下是关于数据采集方式的详细扩展。

3.2.1 REST API 轮询

REST API 轮询是一种常见的数据采集方式，通过定期向交易所的 HTTP REST API 发起请求，获取市场的最新行情数据。这种方式适用于对实时性要求不高的应用场景，特别是需要周期性获取市场数据进行更新的系统。

• 轮询原理：REST API 轮询的原理是按照一定的时间间隔，周期性地发送 HTTP 请求给交易所 API，以获取最新的行情数据、订单簿数据等。例如，每隔 5 秒请求一次市场的最新 K 线数据。交易所通常会提供不同时间周期的 K 线数据（如 1 分钟、5 分钟、1 小时），用户可以根据策略的需求选择合适的时间周期。

• 适用场景：REST API 轮询适用于对实时性要求不高的场景，例如日内交易或中长期趋势跟踪策略。在这些策略中，通常并不需要毫秒级别的市场数据更新，只需分钟或更长时间段的价格走势信息即可。

• 实现的简便性：REST API 轮询的实现相对简单，适合初学者入门和策略的原型开发。通过 HTTP 请求获取数据后，可以进行相应的分析、计算并做出交易决策。此外，REST API 也适合用于历史数据的获取。例如，在策略回测阶段，可以通过 REST API 获取历史的 K 线数据，用于策略的验证和优化。

• 局限性：由于轮询的时间间隔限制，REST API 采集的数据在实时性方面存在较大不足。交易所的 API 通常对请求频率设有限制，例如每秒只能发起 10 次请求。如果频率过高，可能导致请求被拒绝或 IP 被封禁。这样，系统就难以对市场的实时变动做出快速反应。因此，REST API 不适用于高频交易策略，也不适合对市场实时变化有严格要求的场景。

3.2.2 WebSocket 实时推送

WebSocket 实时推送是目前最常用的实时数据采集方式之一，通过建立一个持久化的连接，服务器会主动推送最新的市场数据至客户端。这种方式具有低延迟的优势，适用于对实时性要求较高的应用场景。

• 实时推送原理：WebSocket 是一种全双工通信协议，允许客户端与服务器之间进行实时数据交互。在自动化交易系统中，通过 WebSocket 与交易所建立一个持续的连接后，交易所会实时将市场的最新数据（如价格变动、订单簿深度、交易明细等）主动推送到客户端。客户端只需接收数据并进行处理，无需像 REST API 那样周期性地发起请求。

• 低延迟优势：WebSocket 的主要优势在于低延迟，它能够以毫秒级的速度将最新的数据传递给系统。这对于高频交易策略、套利策略、做市策略等需要对市场变化做出快速反应的场景尤为重要。通过 WebSocket，系统可以第一时间捕捉市场的价格变化，从而及时作出交易决策。

• 数据订阅：WebSocket 实时推送的数据通常是通过订阅的方式获取的。系统可以根据需求订阅特定的市场数据，例如某个交易对的最新成交价格、订单簿的更新情况、实时成交明细等。通过灵活的订阅机制，可以只接收所需的数据，减少不必要的数据传输，降低带宽和处理压力。

• 自动重连机制：由于网络波动或交易所服务器问题，WebSocket 连接可能会断开。因此，WebSocket 客户端需要具备自动重连机制，以确保连接的稳定性和数据的连续性。通常，当检测到连接断开时，系统会在一定时间间隔内尝试重新连接交易所的 WebSocket 服务器，重新订阅需要的数据频道。

• 适用场景：WebSocket 实时推送适用于对市场变动的反应速度有极高要求的策略，例如高频交易、套利交易、做市策略等。在这些场景中，延迟的降低意味着更高的盈利潜力，WebSocket 允许系统在极短时间内捕捉市场的变化并及时执行交易。

3.2.3 REST API 与 WebSocket 的组合使用

为了兼顾实时性和数据完整性，通常在实际应用中会将 REST API 与 WebSocket 结合使用，以弥补单一采集方式的不足，保证系统的鲁棒性和数据的完整性。

• 实时数据与补偿机制：WebSocket 实时推送用于获取市场的最新变动，保证系统的实时响应能力；而 REST API 轮询则用于定期校验数据的完整性。例如，如果在 WebSocket 连接中断后系统未能收到部分数据，可以通过 REST API 请求缺失的数据，以确保系统中的数据是完整的。

• 断线重连的补充：在 WebSocket 断开连接的情况下，系统可以临时使用 REST API 进行数据采集，直到 WebSocket 连接重新建立。这种组合方式可以确保系统在 WebSocket 断开期间依然能够获得市场数据，避免因数据中断导致的交易决策失误。

• 历史数据采集与实时数据结合：REST API 通常用于采集历史数据，而 WebSocket 则用于实时数据的更新。例如，在策略回测阶段，系统可以通过 REST API 获取过去几个月的 K 线数据，而在策略实盘交易阶段，WebSocket 则用于实时行情的推送。

3.2.4 数据采集的优化策略

在数据采集中，选择合适的采集方式只是第一步，如何优化数据采集过程以提高系统性能、降低延迟也是非常重要的。

• 异步 I/O：无论是使用 REST API 还是 WebSocket，数据采集模块都应采用异步 I/O 模型，以提高数据采集的并发能力和响应速度。对于 REST API，可以使用 asyncio 库或 aiohttp 等异步请求库来减少数据采集的阻塞时间；对于 WebSocket，可以使用 websockets 或其他异步框架来实现高效的数据接收和处理。

• 多线程与多进程并行化：对于需要从多个交易所获取数据的系统，可以采用多线程或多进程的方式进行并行数据采集。例如，一个线程用于采集 Binance 的数据，另一个线程用于采集 Huobi 的数据，从而提高数据采集的效率，保证数据的实时性和多样性。

• 数据缓存与限流：为了减轻交易所 API 的负担和避免触发限流机制，可以对已经获取的数据进行缓存。例如，系统可以使用 Redis 等内存数据库来缓存最近几分钟的市场数据，这样在短时间内的重复请求可以直接从缓存中获取，避免频繁向交易所发起相同的请求。

• 智能调度与负载均衡：在多数据源的情况下，可以通过智能调度算法将采集任务合理分配到不同的数据源上。例如，当某个交易所的 REST API 请求频率接近上限时，可以优先从其他交易所获取相同类型的数据，进行负载均衡，保证数据采集的稳定性。

3.2.5 数据采集方式的选择依据

选择合适的数据采集方式，取决于具体的策略需求和系统特性：

• 高频与低频策略：对于高频交易策略，低延迟的 WebSocket 实时推送是必不可少的，因为系统需要在极短时间内响应市场的变化。而对于低频交易策略，如日内交易或中长期趋势跟踪策略，REST API 轮询的方式通常已经足够。

• 数据完整性与实时性平衡：如果策略对数据的完整性要求非常高，例如回测或统计分析，则可以考虑将 REST API 与 WebSocket 结合使用，以保证数据的可靠性和完整性。在此情况下，WebSocket 实时推送提供最新的数据，而 REST API 则用于补充和校验数据，防止因网络中断等因素导致的数据丢失。

• 资源与成本考虑：REST API 请求和 WebSocket 连接都会消耗系统资源，但在不同场景下资源的消耗方式不同。WebSocket 需要保持持续连接，占用系统内存和带宽，而 REST API 需要处理较高频率的请求和响应。根据服务器的配置和网络带宽情况，可以选择合适的采集方式或结合两种方式来平衡资源消耗和系统性能。

3.2.6. 股票/期货/数币数据采集方式：

股票数据更多是应用分析和手工交易，这部分的TICK接入和实盘主要是我的老同事负责开发，在19年接入股票数据费用还挺高的，是基于券商版本软件做的自动化交易，github上有一些可以参考的代码，这部分实盘交易大致上也有了解后面可以再详细整理和交流。

每日收盘后同步到服务器，然后进行分钟和日级加工，再根据TICK、分钟和日级三个维度数据进行深度指标的加工，例如布林、RSI等指标可以通过日数据，但集合竞价、涨停相关、大资金分析都要基于TICK数据。

期货数据开发了TICK数据的接入、数据加工、深度指标分析，简单做了高频交易系统，高频交易策略相对简单，这部分数据是交易所谈的免费的接入的，但数据的种类比较复杂，多空双方向交易，因为涉及不同的品种、合约，这部分数据由于提供深度学习应用，做了不少的加工，当时主要研究的方向是高频交易，通过深度学习生成模型，交易系统根据实时数据窗口灌入模型生成交易指令，然后交易系统再进行买卖交易，主要小价差频繁交易获利，制约还是比较多所以没有实盘。

数字货币数据开发这部分是最全的也是最复杂的，从支持自动化交易的所有数据接入，到交易系统的开发，挂单策略的开发，回测系统的开发。这部分数据都是免费的，甚至可以拿到逐笔数据，多空双方向交易，还有不同的杠杆玩法，实时交易系统除了TICK数据需要soctet获取，其它都是根据实际rest获取，包含TICK数据（用于实时数据合成）、近期分钟级（用于历史数据合成）、5档深度频道数据（用于交易系统挂单策略）、数字货币订单数据（用于交易系统调仓）、数字货币账户数据（用于多币种调仓）。

这部分基于多币种组合交易模型，所以对于交易系统要求就比较高，其中最重要的一些成本是手续费成本、未成交成本、滑点成本，由于我们的交易频率比较高，虽然跟交易所谈的手续费成本很低，甚至有些是负的，但如果45分钟交易窗口，当时粗略算了一年交易下来各种成本达到了本金的2-3倍，所以成本控制也是非常重要的，这也就是交易系统需要做好的，后面也可以详细说说此部分。