本文討論一下數據監聽線程和訂單管理線程做些什麼。一，數據監聽線程
數據監聽線程，當行情處理線程接收到新的行情數據時，也就是每當一個tick到來時，就向數據監聽線程發出信號，觸發此線程啓動，然後依次進行：
1.各種指標計算，
2.然後進行策略計算，
3.最後在滿足策略時進行交易。
指標計算，就是指根據新到來的數據以及歷史數據進行某些統計值的計算，比如常見的MA，MACD，RSI等，當然也可以自己構造出某個統計值。這裏需要提到的是數據週期的問題（我在之前的博文中曾解釋過）。如果指標計算是基於數據週期，那麼對於行情數據就要進行數據的拼裝，也就是說將每一tick數據（500毫秒）拼裝成你所需要的數據週期（也就是拼裝成K線），然後將每個週期（每根k線）中的open，high，low，close計算出來，以便進行統計值的計算。
策略計算就是將你的計算出來的指標，按照你自己的交易思想，交易策略進行邏輯的組合，然後在滿足策略邏輯的時候進行交易。
這裏我建議一下架構，就是不要將指標計算和策略計算以及交易寫到一個函數裏面，而是將每一個指標計算寫成一個函數，然後分別用函數指針指向它；然後策略計算以及交易寫成一個函數，然後用函數指針指向它，並將其壓入一個堆棧，此後每添加一個指標，就將指標對應的函數指針壓入堆棧；
當每次數據監聽線程啓動時就依次彈出每個指標並計算，最後完成策略函數。
二，訂單管理線程
訂單管理線程，主要是用於處理訂單管理中的兩個問題：
1.訂單隊列的管理，一般按照報單的時間先後順序用數組等數據結構進行管理，原則是每一個業務請求要準確對應其回報，每一組請求和回報要準確的對應其歸屬的訂單。其關鍵就在於業務請求編號和交易序列號。
業務請求號是指發送請求時設定的RequestID，TraderApi返回響應時返回相關請求的RequestID。因爲TraderApi是異步實現的，終端程序可能連續發出多個請求和查詢指令。RequestID可以把請求/查詢指令和相關的回報關聯起來。
而交易序列號是組合而成的。從報單到成交的交易過程中，會產生如下幾組交易序列號：
FrontID + SessionID + OrderRef
用戶使用這組交易序列號可以按照自己的方式來唯一標示發出的任何一筆委託。用戶登入成功後，會收到前置機編號FrontID, 會話編號SessionID 和最大報單引用MaxOrderRef。用戶在報單時設定報單引用OrderRef。 OrderRef可以從MaxOrderRef開始遞增。如果用戶沒有設定OrderRef，在報單響應中，Thost會爲用戶設置一個的OrderRef。使得每個報單的這組序列號保持唯一。
通過這個交易序列號，就可以確定委託回報和成交回報的歸屬，也可以使用這組交易序列號進行撤單操作。
2.訂單的各種狀態的管理：在回報中，訂單的狀態有很多種，請參考ThostFtdcUserApiDataType.h，我建議根據其含義歸納爲這五種狀態：報單中，已成交，撤單中，已撤單，出錯，因爲這五種狀態對於策略邏輯的完成是至關重要的。
下面說一下訂單交易的機制與時序。先給出一個時序圖:
其中，報單響應和回報的機制是當Thost收到報單指令，如果沒有通過參數校驗，拒絕接受報單指令。用戶就會收到OnRspOrderInsert消息，其中包含了錯誤編碼和錯誤消息。如果Thost接受了報單指令，用戶不會收到OnRspOrderInser，而會收到OnRtnOrder，用來更新委託狀態。交易所收到報單後，通過校驗。用戶會收到OnRtnOrder、OnRtnTrade。如果交易所認爲報單錯誤，用戶就會收到OnErrRtnOrder。
撤單響應和回報和報單響應和回報相似。當Thost收到撤單指令，如果沒有通過參數校驗，拒絕接受撤單指令。用戶就會收到OnRspOrderAction消息，其中包含了錯誤編碼和錯誤消息。如果Thost接受了撤單指令，用戶不會收到OnRspOrderAction，而會收到OnRtnOrder，用來更新委託狀態。交易所收到撤單後，通過校驗，執行了撤單操作。用戶會收到OnRtnOrder。如果交易所認爲報單錯誤，用戶就會收到OnErrRtnOrderAction。