1. 典型数据汇总
数据 |
说明 |
新增数据量(条/天) |
Qps(条/s) |
消息大小(Byte) |
实时性 |
可丢失性 |
可恢复性 |
实时行情 |
1.使用场景:交易,报价,策略验证; 2.冷热分离:彭博行情/其他行情;黄金&期货行情/固守行情 |
5亿 |
3万 |
1.5K |
< 5ms |
< 5% |
N |
风控数据 |
容易造成BigKey问题 数据事后风控 |
500万 |
3万 |
50K |
分钟级别 |
可丢失 |
N |
监控数据 |
数据种类: 1.中间件监控 2.应用监控 |
10亿 |
5万 |
215 |
亚分钟级别 |
可丢失 |
N |
excel报价数据 |
做市报价 |
3亿 |
2万 |
3M |
亚秒 |
可丢失 |
N |
订单数据 |
含做市 |
1千万 |
1万 |
1.5K |
< 3ms |
不可丢失 |
Y |
权限数据 |
权限控制粒度小 容易造成HotKey问题 |
1千万 | 5万 | 215 | < 1ms | 不可丢失 | Y |
通过上表,我们可以知道,金融交易系统的数据具有以下特点:高性能,高并发,数据量极大...
2. 海量数据
交易系统的数据量特大,主要来自以下几种类型的数据。
2.1 行情
行情是交易系统最为重要的数据,交易就是在不断变化的行情中寻找时机来实现盈利的。海量的行情主要分成两种,一种是tick数据(也叫逐笔行情),例如彭博行情数据,它会将每一笔交易的行情都发布出来,这种数据量巨大,一天就有4亿多条数据;另一种是每隔500ms发布一次行情,这种相对来说数据量少很多,一天大概1亿条左右。再加上各家公司会根据需求对行情进行进一步的加工,如聚合多种行情形成的聚合行情。数据量一天就会达到5亿多条。
2.2 报价
作为做市商,需要根据行情,通过一定的算法(如跟随当前行情报价、根据设定的差值及当前行情报价,根据行情计算曲线,然后报价)对外报价。报价数据一天的数据量能达到3亿条。
2.3 监控
监控数据主要包括中间件的监控数据,服务实例的内存和CPU监控数据等,数据量和QPS非常高。一天的数据量能达到10亿条,在进行监控图标展示时,必须进行采样处理。
3. 高并发
3.1 行情
对于行情而言,QPS基本保持在3万/s以上,高峰时段(国内交易时间9:00 - 11:30左右,国外交易时间21:.00 - 23:00)的QPS能达到3万/s。
3.2 权限
对于交易高峰时段(手动单,电子单,做市,量化),会造成权限数据的访问频繁达到5万/s。主要是读高峰,权限写操作比较少,而且一般在开始交易前就已经完成。
3.3 监控
监控数据的峰值能达到5万/s,主要是写操作并发高。
3.4 风控
风控数据分成两种,一种是partial batch,数据量少,时间间隔短,例如每10s计算一次;另一种是full batch,会根据当前行情全量计算一次所有产品的风控指标数据,例如每30min计算一次。由于full batch的计算量大,而且希望结果能够一次性给到交易员查看,议事交易员能够看到不同产品的统一切面数据,导致风控数据的瞬间并发值特别高,达到3万/s。
3.5 报价
由于做市交易和量化交易的存在,导致报价数据量特别大,峰值能够达到2万/s。
3.6 订单
交易方式的多样化,如手工单,电子单,做市交易以及量化交易,再加上订单策略,如冰山策略等,导致订单的并发量在高峰时可以达到1万/s。
4. 高性能
交易系统的高性能主要体现在延时性上。
4.1 行情
4.1.1 实时行情
实时行情分量两大类,一类是当前会进行交易的产品行情数据,另一类是计划以后会进行交易,当前只是用于策略测试的行情数据。
对于会进行交易的产品行情数据,要求交易所或数据商的数据进入交易系统后,必须在3ms以内推送到各个下游服务(其实,订阅方根据业务逻辑也会对延时有不同的要求,可以进一步细分,依次来降低MQ的压力,这些待MQ的章节进行介绍)。
对于当前只是用于策略测试的行情数据,对于行情的延时没有太大的要求,一般卡在亚分钟级别即可。
行情数据的流向图见下图:
行情的延时是从行情数据进入行情接入服务后开始计算,行情接入服务接收到交易所推送的行情后,需要将行情进行加工和包装,让其符合内部的使用场景,例如数据校验、与对应的市场参考数据匹配、与其他行情数据进行聚合、填充必要标识...,最后封装成统一的对象供下游使用。
行情接入服务处理完毕之后,将行情发布到MQ,由MQ推送给下游的各个订阅服务。
整个交易系统的内部网络环境如下:内部的网络延时大概是在50us,带宽是万兆网。延时要求小于5ms。从消息进入行情接入服务开始计算,至消息进入下游订阅服务为止。耗时主要发生在行情的接入服务,以及消息在MQ中的主从复制和消息路由。
行情数据对延时的要求还一定程度上受交易品种的影响,例如,对于黄金和期货产品而言,由于玩家较多,行情数据的延时对成交影响很多,要求延时在3ms以内;而对于固收类产品,由于玩家少,行情数据的延时对成交的影响也弱的多,可以将延时放宽到5ms。
4.1.2 历史行情
历史行情主要用于策略研究和曲线拟合。两种业务场景都只要求近三年的数据,因此三年之前的数据可以直接进行存档。对于三年内的数据,曲线拟合要求数据延时在30s以内,而策略研究,通常没有太大的限制,只要不导致请求超时即可,我们常按照分钟级别的要求进行设置。
4.2 订单
交易所通常按照价格优先,时间优先的规则进行撮合,因此订单早一刻到达交易所,成交的概率就更大。
订单的延时从订单生成时刻起算,直到将交易所ack为止。这中间主要经历订单校验、权限检查、风控检查、策略拆单、订单路由等步骤,然后由外联系统将订单发送到交易所。整个过程的耗时不可超过3ms。
其实,订单还可以分类,例如指定交易对手方的交易,通常对延时不太敏感;对于RTF/RFQ模式的交易,对延时也要求不高。
4.3 权限
由于订单的下发处理过程中,首先就是要做权限校验,因此系统对权限的延时i性能要求更高,一般权限的延时不能超过1ms。
同时权限有一些自身的特点,例如并发性极高,因此,一定要区分不同场景对权限延时的要求,区分对待。
5. 高可用
金融交易系统:稳是第一要务,稳是第一要务,稳是第一要务。
为了提高可用性,金融行业的一个惯例做法是每周重启系统,并不是对可用性没有要求,而正是为了在交易时间段不出现不可用状态。
而且需要避免单节点故障,搭建同城双活,异地多活架构。文章来源:https://www.toymoban.com/news/detail-826960.html
6. 消息体大
小的消息在几百个字节,大的数据可以达到3-5M。大消息体的消息会对序列化、网络传输、数据落盘产生非常大的影响。文章来源地址https://www.toymoban.com/news/detail-826960.html
到了这里,关于[BIZ] - 1.金融交易系统特点的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!