數字貨幣交易平台后端性能測試思路

原創發布：https://www.cnblogs.com/huanghaopeng/
作者信息：HHP

本篇博客內容有大量刪減

一、概述

數字貨幣交易平台通常提供：幣幣交易、合約交易、法幣交易。本篇博客提供前面兩者的一種性能測試思路。

關於需求的優先級

對於交易系統來說，“數據一致性”和“性能”的優先級排序上，前者優先級更高，因此一切性能測試的最終結果除了確認性能符合預期，也應包含對數據一致性的校驗（如：資金的賬戶、金額、狀態），並實現場景執行前、中、后的資金對賬校驗。

關於壓測的關注點

交易系統功能核心是訂單的處理，訂單的處理主要包括：定序、撮合、清算。

• 定序也就是把用戶的買、賣單按照價格和時間的優先級進行排序。
• 撮合也就是把用戶的買、賣單按照排序結果進行交易、並扣取相應手續費。
• 清算也就是根據用戶的掛單、合約盈虧進行賬戶資金更新。

目前大部分數字貨幣交易所的只有清算是基於數據庫事務的，定序和撮合的工作在內存實現了。

業界所謂的支持高並發

某些交易所所謂的能支撐十萬級、甚至百萬級並發，實質上並不是指其撮合性能，而是指測試人員針對下單接口的壓測得出的壓測數據，和系統的實際撮合性能是兩碼事。試想，你掛了買單、市場上有個能和你撮合的賣單，但是系統就偏偏不做撮合，純粹接口響應快又有什么意義？

小結

所以，對於數字貨幣交易所的壓測，“性能”是否能夠真正滿足用戶可以分成兩個角度來觀測：

1. 用戶看到的：即接口和推送的延遲，例如行情推送是否存在延遲、下單接口的反饋、委托當中委托的執行狀態刷新延遲
2. 用戶看不到，但能被用戶感知的：簡單來說就是后台對訂單的處理效率，例如：用戶設置了止盈委托，行情也到達了止盈條件，但是委托單的執行總是需要延后幾秒才反饋在交易頁面，這種延遲又並非來自於推送或網絡的延遲，而是系統對委托單的處理效率過低導致的

二、性能需求分析

內部評估

由於交易所項目運營在不同階段也有不同的傾向性，因此評估重點也有所不同：

第一階段：從 官網白皮書發布 至 開放用戶注冊

• 開放注冊、開放邀請返利、開放充值所需支持新增的用戶數、在線用戶數

第二階段：開放交易日

• 開放交易當日需支持在線用戶數（行情服務需提供飽和支撐）
• 開放交易當日 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 合約的系統強平處理效率
• ……

六、數據一致性關注點

在行情、匯率出現大量波動的前置條件下：

• 幣幣交易：關注平台資金在大批量的充幣、提幣、幣幣交易、賬戶內划轉操作中的整體資金正確性
• 合約交易：關注平台資金在大量的開倉、平倉、爆倉中，整體資金的正確性，避免用戶出現穿倉
• ……