分布式期货行情交易系统-架构设计

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

 

目录

文章目录

前言

一、系统架构图

​

二、功能分析

1.客户端

2. 前置

3.实时行情采集

4.K线服务

5.交易服务

6 云条件单

注意事项

---

 

---

前言

一、系统架构图

根据对系统的分析以及本身开发人员对技术的熟练度，选取消息队列kafka来实现对系统的解耦，选取zookeeper来对整个系统进行分布式管理，数据库选用了开源分布式数据库TDengine。

系统架构图如下图：

二、功能分析

1.客户端

客户端通过配置连接不同的前置服务器，更优的做法是客户端根据网络测试自动选择最优前置建立scoket长连接。

2. 前置

设计行情系统为开放系统(无需注册科直接使用)，则用户是匿名连接，按规则为每个连接生成全局不同guid（前置id_socket）来标识客户端。

交易和行情分别建立单独的长连接。

行情请求是匿名的，可以提交给任意K线服务处理，可以通过Kafka本身实现负载均衡(后面将在Kafka系统介绍中讲)；

交易请求在第一条登录请求确定交易服务后，后继的请求都必须持续由该服务处理，因此，对交易请求通过负载均衡算法（交易账号和期货公司编码作为hash算法key）来实现消息的分发。

3.实时行情采集

通过行情API获取实时行情，异步处理：入库（如果存储的话)，同时生成基础K线数据入库。

4.K线服务

根据客户端的请求来查询数据库TDengine及Redis，生成客户端所需的K线数组。

5.交易服务

交易服务分为多个进程：用户管理主进程及交易子进程(每一种类型的交易API运行一个进程)，交易子进程和用户管理主进程通过socket通信(也可通过其他方式进行进程间通信)。

用户管理主进程启动后开启服务端口监听，然后启动交易子进程，交易子进程启动后与用户管理主进程建立连接。

交易子进程是必须支持多交易用户同时登陆。

用户管理主进程根据提交的交易客户(客户端提交登录请求时设定使用哪种类型的接口，一般是**CTP服务器/**恒生服务器)转交给相应的交易子进程处理。

6 云条件单

• 价格触发云条件单

价格云条件单触发主要是实时行情，实时行情来源有两种：一种是实时行情服务提交到消息队列kafka中的数据，另一种是来源于行情API。为了保证速度选用行情API。

收到条件单处理逻辑分三步：1.根据交易合约编码先分组；2.按大于或者小于再分组；3.组内根据触发价格顺序排序。

触发处理逻辑：收到实时行情，根据实时行情合约编码查找分组，大于组中触发价格大于实时行情价格的所有单子触发，小于组中触发价格小于实时行情价格的所有的单子触发。

• 时间触发云条件单

避免服务器时间存在不准确的可能性，利用实时行情的时间来触发时间云条件单。

注意事项

国内期货品种已超过50个品种，每个品种相对活跃的合约约为3个，实际每秒钟收到实时行情数据约为50 * 3 * 2=300多条，每条行情数据按2KB计算，每秒钟有600多K数据，因此如果要保存实时行情数据需要巨大的存储空间。