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。大消息体的消息会对序列化、网络传输、数据落盘产生非常大的影响。