第1章：核心需求分析——功能需求与非功能需求

各位同学，咱们今天聊聊跨市场多节点交易系统的核心需求。说实话，我见过不少团队一上来就撸代码，结果做到一半发现需求没理清，返工成本高得吓人。所以，咱们先把需求这块掰开揉碎了讲清楚。

1.1 功能需求：系统得能干哪些活？

功能需求，说白了就是系统必须具备的能力。我把它拆成三大块：订单管理、行情订阅、风控。这三块缺一不可，就像人的手、眼、脑。

1.1.1 订单管理

订单管理是交易系统的核心。嗯，这里要注意，跨市场场景下，订单的生命周期比单市场复杂得多。

• 订单创建：支持市价单、限价单、止损单等常见类型。我个人习惯把订单类型做成可配置的，方便后续扩展。
• 订单路由：根据市场规则和流动性，把订单发到最优的交易所。我在项目中遇到过，有些交易所对订单大小有限制，路由策略必须考虑这一点。
• 订单状态管理：从“已提交”到“部分成交”再到“完全成交”或“已取消”，状态机必须严谨。我曾经因为状态转换没处理好，导致一笔订单被重复执行，那叫一个惨。
• 订单撤销与修改：支持部分撤销和修改订单参数。注意，有些市场不允许修改订单，只能撤销重下。

1.1.2 行情订阅

行情数据是交易决策的基础。你想想看，如果行情延迟了1秒，在高频交易场景下可能就错过几百万的利润。

• 多数据源接入：支持从不同交易所、数据供应商获取实时行情。我建议用发布-订阅模式，解耦数据生产者和消费者。
• 行情快照与增量：既要支持全量快照（比如每天开盘时的数据），也要支持增量更新（比如逐笔成交）。
• 行情缓存：本地缓存最近N条行情数据，避免频繁请求远程服务。我一般用Redis或者内存缓存，看具体场景。
• 行情推送：支持WebSocket、TCP长连接等推送方式。为什么不用HTTP轮询？因为延迟太高，而且浪费带宽。

1.1.3 风控

风控是交易系统的生命线。没有风控，系统就像脱缰的野马，随时可能出事。

• 事前风控：订单提交前检查，比如资金是否充足、持仓是否超限、价格是否在合理范围内。
• 事中风控：订单执行过程中监控，比如检测异常交易行为、市场波动率突变。
• 事后风控：交易完成后分析，比如计算盈亏、生成风控报告。
• 熔断机制：当市场出现极端波动时，自动暂停交易。我曾经在某个项目中，因为熔断阈值设置得太低，导致系统频繁触发熔断，影响了正常交易。

1.2 非功能需求：系统得跑得稳、跑得快、跑得远

功能需求决定了系统能做什么，非功能需求决定了系统做得好不好。我重点讲三个：高可用、低延迟、可扩展。

1.2.1 高可用

交易系统不能宕机，哪怕1秒钟都不行。你想想看，如果系统在交易高峰期挂了，客户会怎么想？

• 冗余部署：关键服务至少部署2个实例，避免单点故障。我习惯用主备模式，主节点挂了，备节点秒级接管。
• 故障转移：当某个节点不可用时，自动将流量切换到其他节点。这里要注意，切换过程中不能丢数据。
• 数据持久化：所有交易数据必须落盘，并且做异地备份。我建议用分布式数据库（比如TiDB）或者消息队列（比如Kafka）来保证数据不丢失。
• 健康检查：定期检查各服务的状态，发现异常及时告警。我一般用心跳机制，每隔几秒发一次心跳。

1.2.2 低延迟

在交易领域，延迟就是金钱。每毫秒的延迟都可能影响交易结果。

• 网络优化：使用专线连接交易所，减少网络跳数。我建议把服务器部署在离交易所最近的数据中心。
• 协议选择：使用UDP或者自定义TCP协议，减少协议开销。为什么不用HTTP？因为HTTP的头部太大了，不适合高频场景。
• 内存计算：尽量在内存中完成计算，避免磁盘I/O。我一般用Java的堆外内存或者C++的直接内存访问。
• 零拷贝：在数据传输过程中，避免数据在内核空间和用户空间之间来回拷贝。Linux的sendfile系统调用就是个好例子。

1.2.3 可扩展

业务量会增长，系统必须能平滑扩展。你不能说业务翻倍了，系统就得重构。

• 水平扩展：通过增加节点来提升系统容量。我建议用无状态服务设计，这样扩展起来最方便。
• 分片策略：按市场、按品种、按客户进行数据分片。比如，把美股和A股的数据分别存储在不同的分片上。
• 异步处理：用消息队列解耦各个模块，这样某个模块的负载增加不会影响其他模块。
• 插件化架构：把核心功能和扩展功能分开，方便后续添加新功能。比如，新增一个交易所，只需要开发对应的插件即可。

1.3 知识体系总览

下面这张图展示了本章的核心知识结构，方便你快速回顾。

好了，核心需求这块就讲到这里。记住，需求分析是系统设计的基石，地基打不牢，后面盖再高的楼也是白搭。下一章咱们聊聊系统架构的整体设计，到时候我会结合具体案例，把今天讲的需求落地成实际的技术方案。

---