数字货币交易平台后端性能测试思路
原创发布：https://www.cnblogs.com/huanghaopeng/
作者信息：HHP
本篇博客内容有大量删减
一、概述
数字货币交易平台通常提供：币币交易、合约交易、法币交易。本篇博客提供前面两者的一种性能测试思路。
关于需求的优先级
对于交易系统来说，“数据一致性”和“性能”的优先级排序上，前者优先级更高，因此一切性能测试的最终结果除了确认性能符合预期，也应包含对数据一致性的校验（如：资金的账户、金额、状态），并实现场景执行前、中、后的资金对账校验。
关于压测的关注点
交易系统功能核心是订单的处理，订单的处理主要包括：定序、撮合、清算。
- 定序也就是把用户的买、卖单按照价格和时间的优先级进行排序。
- 撮合也就是把用户的买、卖单按照排序结果进行交易、并扣取相应手续费。
- 清算也就是根据用户的挂单、合约盈亏进行账户资金更新。
目前大部分数字货币交易所的只有清算是基于数据库事务的，定序和撮合的工作在内存实现了。
业界所谓的支持高并发
某些交易所所谓的能支撑十万级、甚至百万级并发，实质上并不是指其撮合性能，而是指测试人员针对下单接口的压测得出的压测数据，和系统的实际撮合性能是两码事。试想，你挂了买单、市场上有个能和你撮合的卖单，但是系统就偏偏不做撮合，纯粹接口响应快又有什么意义？
小结
所以，对于数字货币交易所的压测，“性能”是否能够真正满足用户可以分成两个角度来观测：
- 用户看到的：即接口和推送的延迟，例如行情推送是否存在延迟、下单接口的反馈、委托当中委托的执行状态刷新延迟
- 用户看不到，但能被用户感知的：简单来说就是后台对订单的处理效率，例如：用户设置了止盈委托，行情也到达了止盈条件，但是委托单的执行总是需要延后几秒才反馈在交易页面，这种延迟又并非来自于推送或网络的延迟，而是系统对委托单的处理效率过低导致的
二、性能需求分析
内部评估
由于交易所项目运营在不同阶段也有不同的倾向性，因此评估重点也有所不同：
第一阶段：从 官网白皮书发布 至 开放用户注册
- 开放注册、开放邀请返利、开放充值所需支持新增的用户数、在线用户数
第二阶段：开放交易日
- 开放交易当日需支持在线用户数（行情服务需提供饱和支撑）
- 开放交易当日 15分钟 / 60分钟 / 24小时 的最高交易：委托量、持仓量、交易撮合量 等
第三阶段：转运维
- 系统每日所需支持在线用户数
- 系统每日所需支持交易量：委托量、持仓量、交易撮合量 等
评估说明：
- 在前期压测中，对以上内容的评估结果用于编写性能测试计划、方案
- 开放交易日 当天几乎不可能迎来注册高峰（炒过币的都懂），因此开放交易日当天的在线用户数可参考前期注册用户数以及容量规划测试结果进行服务节点增减
- 转运维阶段后，参考链上的重大事件（如：减产、攻击、安全事故、奖励规则修改）与日常交易量，随时对服务节点进行增减，没有必要让资源开销保持在太低的水位
不同视角对性能的期望：
| 视角 | 性能体验/需求 |
|---|---|
| 用户视角 | 行情的推送延迟（如：K线、汇率、挂单）、交易接口的延迟（下单、撤单、委托、状态更新）、其它 |
| 运维视角 | 数据一致性、容灾、容错、可用性、扩容 |
| 开发视角 | 数据一致性、订单排序、撮合效率、清算效率 |
| 币币交易 | 系统可承载最高持仓单量、最高委托单量、撮合性能 |
| 合约交易 | 系统可承载最高持仓单量、委托单量、大批量爆仓时系统强平效率、撮合与清算服务的横向扩容能力 |
关键需求（优先级从高至低）
- 可靠性：数据一致性、节点/服务/网络故障的容错能力
- 可用性：稳定运行时长、容灾
- 高性能：延迟、效率
三、测试实现
通讯协议
- 交易相关：HTTP（S）
- 市场行情：WebSocket
测试工具
需求：
易于实现高并发、可自定义 client
工具
| 工具 | 支持协议 | 说明 |
|---|---|---|
| Locust | 自带 HTTP Client，其它协议需自行实现 Client | 采用（单进程）协程+IO复用实现并发负载 |
四、币币交易 - 测试策略
1）核心角色与业务
- 略
2）测试用例注意点
- 行情需充分确保：交易对、买/卖、深度、汇率 覆盖所有交易场景
- 挂单需充分确保：交易对、买/卖、价格、手数、止盈/止损 覆盖所有交易场景
- 行情生成时可依据时间特点，生成特殊标记的行情标记，例如价格、手数中带入时间戳信息，测试脚本即可依据接收行情时间与行情数据解析后的相减处理得到实际行情延迟，从而能够计算出每一个行情推送的响应样本数据
- 挂单内容需要可控，需确保覆盖订单的：部分撮合、完全撮合、不撮合 三种场景
- 挂单内容可依据请求发起时间，带入特殊标的时间标记，用于数据库中批量校验撮合、账户清算实际时间
- ……
3）测试场景设计关注点
测试场景的测试目标，包括：
- 略
因此，关注特定环境配置下可支持的挂单、撮合、清算 性能
- 大量创建不符合撮合条件的挂单、委托
- 大量创建符合撮合条件的挂单、委托
- 并发创建不符合撮合条件的挂单、委托
- 并发创建符合撮合条件的挂单、委托
- 行情消息队列行情推送延迟、送达率
- 行情消息队列可支撑最高的连接数
- 行情消息队列连接的稳定性
- ……
4）测试场景设计需覆盖
- 前期市场运营推广中的产生的异常负载场景，重点：注册登录、邀请返利结算、钱包充提币
- 行情剧烈波动下的负载场景，重点：撮合、委托执行效率
- 日常运营中，峰值负载场景
- 日常运营中，峰值负载场景 * n%
- 由于行情、汇率、交易、账户服务异常而引发的异常负载
- 由于程序异常、主机节点异常、网络异常、第三方接口异常 等 产生相关可靠性测试场景
- 可用性测试场景
- ……
五、币币交易 - 测试策略
1）核心角色与业务
- 略
2）测试用例注意点
- 略
3）测试场景设计关注点
测试场景的测试目标，包括：
- 系统可支持最高的持仓单，如：10000 单 / 1 交易服务节点
- 系统可支持最高的委托单，如：10000 单 / 1 交易服务节点
- 系统对持仓单执行市价平仓的最高处理效率，如：5000 单 / 1 秒/ 1 交易服务节点
- 系统对委托单执行预设委托的最高处理效率，如：5000 单 / 1 秒 / 1 交易服务节点
- 系统强行平仓的最高处理效率，如：5000 单 / 1秒 / 1 交易节点
- 系统对交易服务节点进行增加的过程中，可能产生的衰减
- ……
因此，关注特定环境配置下可支持的持仓单、委托单、撮合 性能：
- 略
4）测试场景设计需覆盖
- 大批量的市价开仓性能测试
- 大批量的市价平仓性能测试
- 大批量的委托开仓、创建止盈止损委托，不触发委托执行
- 大批量的委托开仓、创建止盈止损委托，并触发委托执行
- 大批量的穿仓性能测试场景：通过预先配置测试账户较低的资金余额、创建大量持仓单
- 大批量的爆仓性能测试场景：通过预先配置测试账户资金、创建符合要求的持仓合约量、配置爆仓风险率阈值，然后通过行情波动的模拟，实现瞬间批量爆仓测试，测试系统对5000、10000、20000 合约的系统强平处理效率
- ……
六、数据一致性关注点
在行情、汇率出现大量波动的前置条件下：
- 币币交易：关注平台资金在大批量的充币、提币、币币交易、账户内划转操作中的整体资金正确性
- 合约交易：关注平台资金在大量的开仓、平仓、爆仓中，整体资金的正确性，避免用户出现穿仓
- ……