本文主要是介绍[BIZ] - 1.金融交易系统特点，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
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 |
| 订单数据 | 含做市 | 200万 | 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。大消息体的消息会对序列化、网络传输、数据落盘产生非常大的影响。
这篇关于[BIZ] - 1.金融交易系统特点的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
