分布式期货行情交易系统-架构设计
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
目录
文章目录
前言
一、系统架构图
二、功能分析
1.客户端
2. 前置
4.K线服务
5.交易服务
6 云条件单
注意事项
前言 一、系统架构图
根据对系统的分析以及本身开发人员对技术的熟练度，选取消息队列kafka来实现对系统的解耦，选取来对整个系统进行分布式管理，数据库选用了开源分布式数据库。
系统架构图如下图：
二、功能分析 1.客户端
客户端通过配置连接不同的前置服务器，更优的做法是客户端根据网络测试自动选择最优前置建立长连接。
2. 前置
设计行情系统为开放系统(无需注册科直接使用)，则用户是匿名连接，按规则为每个连接生成全局不同guid（前置）来标识客户端。
交易和行情分别建立单独的长连接。
行情请求是匿名的，可以提交给任意K线服务处理，可以通过Kafka本身实现负载均衡(后面将在Kafka系统介绍中讲)；
交易请求在第一条登录请求确定交易服务后，后继的请求都必须持续由该服务处理，因此，对交易请求通过负载均衡算法（交易账号和期货公司编码作为hash算法key）来实现消息的分发。
3.实时行情采集
通过行情API获取实时行情，异步处理：入库（如果存储的话)，同时生成基础K线数据入库。
4.K线服务
根据客户端的请求来查询数据库及Redis，生成客户端所需的K线数组。
5.交易服务
交易服务分为多个进程：用户管理主进程及交易子进程(每一种类型的交易API运行一个进程)，交易子进程和用户管理主进程通过通信(也可通过其他方式进行进程间通信)。
用户管理主进程启动后开启服务端口监听，然后启动交易子进程，交易子进程启动后与用户管理主进程建立连接。
交易子进程是必须支持多交易用户同时登陆。
用户管理主进程根据提交的交易客户(客户端提交登录请求时设定使用哪种类型的接口，一般是**CTP服务器/**恒生服务器)转交给相应的交易子进程处理。
6 云条件单
价格云条件单触发主要是实时行情，实时行情来源有两种：一种是实时行情服务提交到消息队列kafka中的数据，另一种是来源于行情API。为了保证速度选用行情API。
收到条件单处理逻辑分三步：1.根据交易合约编码先分组；2.按大于或者小于再分组；3.组内根据触发价格顺序排序。
触发处理逻辑：收到实时行情，根据实时行情合约编码查找分组，大于组中触发价格大于实时行情价格的所有单子触发，小于组中触发价格小于实时行情价格的所有的单子触发。
避免服务器时间存在不准确的可能性，利用实时行情的时间来触发时间云条件单。
注意事项
国内期货品种已超过50个品种，每个品种相对活跃的合约约为3个，实际每秒钟收到实时行情数据约为50 * 3 * 2=300多条，每条行情数据按2KB计算，每秒钟有600多K数据，因此如果要保存实时行情数据需要巨大的存储空间。
