从顶层流图来看，交易系统有市场则的指令和数据，以及有用户则的指令和数据，任意一则或两则发起的内容都是流入到实时交易系统中进行路由及处理。但是在低延时实时交易系统内部是一个很复杂的生态系统，本文只抽取描述部分关键的技术架构进行描绘。
定义交易系统核心功能为：
1， 买方和卖方的交易操作（买入，卖出，挂牌，出价，追单，撤单，拆单，合单）。
2， 实时行情广播，实时交易，机构批量交易，高频率交易。
3， 市场资讯。
4， 历史交易，账单。
5， 账号管理，资金管理。
6， 金融机构接口。
7， 实时交易风险管理。
服务器节点性能要求：
交易系统需要使用内存计算架构，交易系统开市过程中响应时间设计的标准为平缓的响应曲线，即不以交易量的线性增长形成与延长响应时间之间的线性关系，都应以20ms左右的响应时间作为同时间段的目标性能，为如下图所示：
低延时交易操作：5ms—20ms/单。
2000+TPS。
20000+在线网络连接。
高可靠事务控制，单一订单不重复处理，不能丢失交易单及交易请求。
内存计算：
对于低延迟系统，如果交易响应迟缓，几乎是立即出局，所以，交易数据的处理必须全部在内存中完成计算和处理，下表列举出各种内存的响应时间，要满足性能要求，必须在计算机主内存完成计算任务。
| 内存 |
延迟 |
| L1 Cache |
1ns |
| L2 Cache |
3ns |
| L3 Cache |
12ns |
| Remote NUMA Node |
40ns |
| Main Memory (DDR DIMM) |
100ns |
| Intel Optane DC Persistent Memory |
350us |
| Intel Optane DC SSD I/O |
<10us |
| NVMe SSD I/O |
25us |
| Random SSD Read 4K |
50-150us |
| Data Center Read |
500us |
| Mechanical Disk Seek |
10ms |
| Data Center Read |
500us |
以登录后的用户为单位，形成的每事务单中，交易单需要的数据，状态全部会在系统运行后在子系统装载，保证交易过程中订单数据和状态的流动不中断不停留。如果内存资源紧张，用户退出系统后或超过会话周期，可以把无活动的用户清理出内存区。
内存计算采用商用方案领域或开源免费方案，根据项目的预算选择，常见SAP HANA, Apache Ignite都是很好的选择如果是企业级商用场景，需要同时考虑以下开源类产品没有的5个功能：数据快照，数据恢复，监控，审计，数据中心复制。
下表中列出方案选项的考虑因素：
|
|
内存数据库(网格类) |
内存数据库 |
| 产品 |
Apache Ignite， Apache Geode, Hazelcast, SAP HANA, Oracle Coherence |
MemSQL VoltDB |
| 主要功能
|
高吞吐量，低延时 |
高吞吐量，低延时 |
| 事务控制 |
|
|
| 分布式运算, 支持1000节点，TB级存储 |
|
|
| 数据查询分析功能 |
支持SQL，通过API操作 |
|
| 数据持久化，数据库同步 |
数据持久化，但只是内存的快照 |
交易指令路由：
为保证低延时实时高并发的业务特性，应将交易区分出不同类别的指令，如有买，卖，追，撤，合，拆等动作。同时交易的商品也应该区分出各类科目/种类的商品，一一对应到分门别类的商品队列缓存中，交易单中会根据商品和指令动作会分别落入对应的队列缓存中。
订单匹配：
匹配原则采用价格优先和时间优先原则，买方按设定的价格和数量挂牌，卖方也按设定的价格和数量挂牌，系统统计不同价格段内买卖双方的汇总数量，买卖订单匹配成功的话，便满足交易条件，系统则进行买卖双方的交易操作。如果买卖双方没有匹配成功，买入订单会挂在商品队列中，卖出订单同样会挂在商品队列中，继续累积和等待。
|
|
成交价格 |
|
订单数量 |
| 卖⑤ |
5.57 |
|
848 |
| 卖④ |
5.56 |
|
1043 |
| 卖③ |
5.55 |
|
1126 |
| 卖② |
5.54 |
|
987 |
| 卖① |
5.53 |
|
207 |
| 成交 |
5.53 |
现手交换， 成功买入63, 成功卖出207 |
270 |
| 买① |
5.52 |
|
955 |
| 买② |
5.51 |
|
660 |
| 买③ |
5.5 |
|
1860 |
| 买④ |
5.49 |
|
1819 |
| 买⑤ |
5.48 |
|
1329 |
匹配引擎：
按一定周期从买卖订单消息队列中提取出买方和卖方的订单，按订单价格汇总出挂单数量，放入Redis作为缓存，同时作为用户端排行数据的源。如果是撤销指令，则在相应的价格牌中去除。成功匹配的买卖双方，生成最终的交易单，放入交易单消息队列，将由最后的核心业务系统对买卖又双方的账户进行交易操作。
API网关：
交易系统通过API提供交互，在系统内部，所有数据访问都先经过API网关。API网关应有以下功能：
定义APIs：SOAP APIs，REST APIs， WebSocket APIs。
执行设定好的服务级别或全局的策略：
安全策略：
- IP地址黑白名单。
- 设备规则，应用程序规则。
- 消息过滤，SQL注入，JSON线程保护。
- OATH 2.0 , API密钥机制。
消息传输策略：
- SOAP到REST的转换。
- 预处理及后处理。
流量策略：
- 路由。
- 负载均衡。
- 服务治理（限流，熔断，容错）。
- 日志监控。
- SLAs监控。
- 缓存服务监控。
行情广播：
客户端到服务端或者是反向的双向数据传输，第一种情况为：从客户端登录用户或匿名用户在软件终端发起，到服务端拉取行情数据，行情广播自身缓存即时行情数据，对于每一个软件端广播即时的价格信息及市场信息。第二种情况为：服务端主动发送行情数据到软件终端，服务端记录登录的客户软件端，逐一点对点发送市场信息。设置一个ClientPool列表，对列表中的IP进行传输。
行情数据源的对接，使用提供方的数据API获取行情资讯，数据到本地系统后，按证券或货币的种类进行划分，放置到缓存系统中提供给下游数据客户，同时数据快照以K线周期写入时序DB中。
风险管理系统：
风险规则，安全规范的规则库，发起交易的订单流经过程会核对交易订单的内容是否合规，能对系统形成第一道保护屏障。
关于风险控制和分析系统所使用的数据，有很大部分为历史数据，和事务型系统使用的数据，列出下表作对比：
| 事务型系统 |
分析型系统 |
| 大部分情况为OLTP |
大部分情况为OLAP |
| 相对较少的操作数据集 |
完整的历史数据集 |
| 事务高吞吐 TPS/OPS |
只读 |
| 响应低延迟 |
吞吐量相对次要 |
| 一致性，要求有事务控制 |
高频执行查询，要求查询低延迟 |
|
|
交互分析查询，动态查询 |
个人用户交易操作界面：
支持查看行情，分析及市场资讯，发起交易，账单，资金管理，账号管理，提供手机APP，WEB，Desktop应用。
机构交易操作界面：
参考成交量规模额外具备高频交易，批量交易。
整体构架图
数据方向：
1． 个人用户发起系统访问，使用APP，Desktop应用可以浏览证券行情，发起证券交易，管理资金资产。发起买入或卖出时，数据流向负载均衡器，通过API网关。
2． API网关把交易请求发送到订单序列服务中累积并形成买卖交易单。
3． 风险管理系统分析和评估当前交易请求是否合规，满足后交易请求会通过匹配路由进入各自商品的交易队列。
4． 匹配引擎获取各个商品队列的订单，订单在各个价格区间，交易数量累积的数据会被匹配引擎进行交易匹配，在当前价格满足的买卖双方的订单则转入下一环节，通过交易路由把订单转入对应的交易订单队列当中。
5． 核心业务处理买卖双方的交易单，对授权账户进行商品持有量及金额更新，对商品交易的库存进行更新。生成交易形成的对账单，保存在RDBMS中。
6． 交易单风控对最终进入交易的订单进行风险控制，如果满足则通过。
7． 更新后商品库存及即时价格信息写入时序DB中，终端应用APP可以实时使用时序数据观察到市场交易情况，同时为商品交易趋势K线图提供展现数据。
8． CDN为异地终端客户提供及时的数据内容分流服务。
9. 机构具有批量交易、高频交易、实时数据分析等高阶功能，从硬件资源方面实际会按功能模块独立部署。