毕业设计做网站难吗,北京北控京奥建设有限公司网站,福州台江区网站建设,dw简易网站怎么做1. 典型数据汇总 数据 说明 新增数据量(条/天) Qps(条/s) 消息大小(Byte) 实时性 可丢失性 可恢复性 实时行情 1.使用场景#xff1a;交易#xff0c;报价#xff0c;策略验证#xff1b; 2.冷热分离#xff1a;彭博行情/其他行情#xff1b;黄金期货行情/…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. 高可用 金融交易系统稳是第一要务稳是第一要务稳是第一要务。 为了提高可用性金融行业的一个惯例做法是每周重启系统并不是对可用性没有要求而正是为了在交易时间段不出现不可用状态。 而且需要避免单节点故障搭建同城双活异地多活架构。 6. 消息体大 小的消息在几百个字节大的数据可以达到3-5M。大消息体的消息会对序列化、网络传输、数据落盘产生非常大的影响。
