市場參與者每日使用的交易所應用程序是前臺報盤程序EzOES。上交所在開發建設新交易系統過程中，廣泛吸收處理不同會員的反饋意見，使得EzOES可為市場參與者提供更高的報盤速率、更易用的操作界面、更快捷的成交回報以及更簡單的備份切換流程等特征。
為使得廣大市場參與者能夠更好地理解和使用EzOES，這里把一些高層設計理念分享出來。如果大家還有更好的主意，也請反饋。
一、跨市場統一架構以及開放性監控接口
二、層次接入模型以及多環境概念
三、防重復登錄以及雙向心跳
四、成交回報推送以及重傳機制
五、獨立日歷以及前后臺時鐘同步機制
六、后臺防重單以及前臺斷網重連機制
七、滑動窗口以及流速權控制
本文內容為個人觀點，不代表任何機構或者組織意見，不保證內容完全準確。
如果對本博http://blog.sina.com.cn/drwjf內容進行摘錄和轉載，請保留本段說明。
?????????????????????????????????????????????????武劍鋒


廣大市場參與者可以直接接觸到新交易系統的部分是報盤應用程序。該應用程序是市場參與者系統與交易所系統之間的“網關”，負責將市場參與者收集到的投資者委托向交易所申報，并接收交易所返回的委托確認和成交確認。

在2006年時，上交所曾經推出會員集成系統服務器MISS作為報盤應用的載體，供市場參與者試用。由于其集成了行情接收、訂單輸入、成交接收、報表下載、自動升級等功能，且支持設備間故障接管，支持單向衛星鏈路，在支持傳統數據庫接口的同時，也支持STEP1.0 / FIX 4.2接口，相對比較復雜，導致其性能和穩定性不能滿足市場參與者的需求。

在2007年，上交所通過走訪會員，重新設計了報盤應用子系統EzOES 和報表下載子系統 RptGet，沿用單向衛星接收子系統SatReceiver。與MISS相比，降低了報盤應用的使用復雜性，提高了報盤性能和系統穩定性。運行該程序的計算機通稱“報盤機”。

在2008年，上交所通過邀請“先鋒會員”對內部版本進行多輪試用，并組織討論，采納大家提出的很有價值的建議，之后進一步對用戶界面、接口方式進行了改進。

本章結合新交易系統后臺的一些設計特征，介紹前臺報盤應用的內在設計邏輯。

一、跨市場統一架構以及開放性監控接口
上交所通過這次新交易系統的升級，集約化了后臺部分，把A股市場與B股市場統一到了一套系統內部，A股市場被切分為6個產品集（編號從1到6），而B股由于規模小，只是整個系統中的另外一個產品集（編號為20）。這樣的設計方式即簡化了后臺整體的架構和邏輯，也保證了A股交易和B股交易對外時鐘同步功能、接口設計、系統管理等各個方面的一致。在這個前提下，A股與B股兩個市場的前、后臺擁有了共用完全相同的同一套代碼的能力。同時，這樣的改進還使得未來再有不同交易貨幣或者不同交易機制規則的產品推出時，系統后臺和前臺都無需進行大的部署調整。

但是為維持市場用戶習慣，A股和B股的前臺應用程序還是強制性地控制需要分別啟動，EzOES的執行文件以及配置文件中仍然區分A股還是B股。子目錄\cfgA下放置A股配置文件，\cfgB下放置B股配置文件。

EzOES提供開放的監控接口，在運行時，實時（缺省配置為2秒）生成運行狀態文件ASHR_status.txt。文件以類似ini文件的格式提供，便于其他定制的程序處理。該文件揭示內容有市場類型、OES狀態、交易員狀態、當前工作、PBU報單數、委托確認數、成交數、流速權、接口表最大記錄號等。

二、層次接入模型以及多環境概念
上交所新交易系統核心后臺分層設計，可概括為“接入層”與“核心層”。EzOES不能直接訪問到上交所后臺的“核心層”部分，它們直接連接到的是我們稱之為一組“通信服務器”（以下簡稱CS）的“接入層”子系統。

為了支持在系統部署期間、演練期間和切換上線時的平穩，新交易系統增加了一批新的IP地址供市場參與者接入。新的CS設計和功能與原有的“交易前置機GW”有所不同，并且CS在IP地址、設備命名、接入負載等方面進行了重新規劃，規范了定義和分區。

參加過系統切換上線準備工作的市場參與者應該還記得，通過查找地址映射表，從GW IP地址定位到應該接入的CS IP地址的過程。

上交所交易系統核心部分部署在兩個相隔20公里只上的獨立數據中心，市場參與者可以通過查看CS IP地址從左起數第三位，根據其是否大于130來判斷CS位于上交所哪一個數據中心，然后評估自身系統接入上交所交易系統的“容災”水平。理想的情況是，至少有兩個鏈路，分別接入上交所這兩個不同的數據中心。

CS作為“應用網關”，將接入市場參與者的廣域網和上交所核心網絡隔離開來。所有EzOES的請求均通過CS代理后才能進入上交所核心子系統。CS進行“匯聚”和“路由”功能，負責把EzOES的請求，根據產品集進行匯聚后，向適當的交易主機發出，也負責把主機給出的響應和成交確認向適當的EzOES發回。

CS高度冗余，EzOES可以通過不同鏈路，連接到不同CS，防止接入層面的“單點故障”。

EzOES和CS之間采用TCP/IP協議，以消息報文的形式傳遞信息。消息報文的傳輸按照兩種類型的模式進行，一個是“請求/響應”的模式，用來處理委托發送、委托響應；登錄、登錄響應這一類的業務。另外一個是“訂閱/廣播”的模式，用來處理成交確認推送這一類的業務。

CS對EzOES提供兩個端口：MD(1**05)和UD(1**06)。EzOES的每個操作員在登錄時通過和MD端口交互來進行校驗，而每個操作員在登錄之后均與UD端口保持一個連接。

由于成本原因，市場參與者通常在與交易所之間的廣域網絡上即進行生產，也用于測試。為降低風險，新系統提供了“多環境”的機制。多環境通過環境號來隔離生產與測試，目前規劃使用#00環境號作為生產用，使用#88環境號作為測試用。在EzOES啟動時，如果發現環境號不是#00，會彈出對話框請用戶確認。在EzOES啟動后，如果環境號不是#00，整個用戶界面的背景色都會變為粉紅色警示。

三、防重復登錄以及雙向心跳
為了盡快發現可能存在的“錯誤登錄”，市場慣例是當一個操作員登錄成功后，該操作員不能再登錄。當操作員發現自己不能登錄時，可以通過聯系上交所主機房運行人員檢查是否有不該發生的問題。

在歷史上，這個機制確實救過人。某一年，甲證券公司機房信息技術人員被高薪挖到了乙證券公司，繼續從事這個很有前途的職業。甲證券公司在損失一員大將后，正處在從痛苦中恢復的過程中，接替的員工還沒有來得及去修改口令。而這位老兄到了新公司，在緊張和興奮中，就在乙證券公司的機房用甲證券公司的操作員早早地登錄成功。此時，幸虧“防重復登錄機制”發生作用，甲證券公司的接替員工在按時上班時，發現自己不能登錄，迅速報告上交所主機房，避免了一場運行事故。

在Web服務器和瀏覽器的基礎架構設計中，有一個很常用的術語Cookie。而關于這個詞怎么引入信息技術的，即便對我這個“考據愛好者”來說，也沒有找到充分和可信的依據。不過推測應該來自美國或者加拿大的計算機科學家，因為cookie是加拿大和北美專用的詞匯，同樣的“小甜點”在其他英語國家，用的是biscuit這個詞。

Cookie是指Web服務器在用戶的硬盤上存儲的信息，這些信息以名稱/值對的形式存儲，并可在以后檢索此信息。其基本工作原理如果用戶訪問站點上的頁面，瀏覽器會在本地硬盤上查找與該頁面相關聯的Cookie。如果該Cookie存在，瀏覽器就將它與頁面請求一起發送到站點。如果未找到任何Cookie，則不會發送任何Cookie數據。Web服務器接收Cookie數據和頁面請求并可以使用它們。如果未接收到任何Cookie，Web服務器可以知道之前從未訪問過該網站，Web服務器可生成一個新Cookie，放置在它發送的網頁的標頭中，從而發送到客戶計算機上，客戶計算機瀏覽器則可將cookie存儲在硬盤上。通過這樣的工作原理，Cookie能夠幫助Web站點保存有關訪問者的信息。更概括地說，Cookie是一種保持Web應用程序具有狀態的方法。

因為EzOES采用類似的機制實現防止操作員重復登錄的功能，所以我們也把這種技術稱為cookie，詳細過程如下：操作員登錄成功后，后臺給操作員分配的一個唯一的標識符即cookie，cookie由一個64位的整數（8個字節）組成。Cookie是當日不變的，也是當日才有效。

對于配置把Cookie保存到本地文件的操作員，其流程可歸結為下述幾種情況：
（1）該操作員已經連接到CS
不帶cookie或者帶了錯誤的cookie的登錄請求到達后臺后，后臺會拒絕這個登錄請求。表現出來的現象就是“后登錄的沒有cookie的操作員，在前一個操作員未退出時，無法登錄”。

帶正確的cookie的登錄請求到達后臺后，后臺認為是通過同一臺計算機登錄的同一個操作員，接受這個新的登錄請求。在新的登錄請求接受之前，原有的連接會收到特定的消息，該消息帶錯誤代碼，此時EzOES會根據該錯誤代碼把原登錄操作員退出并斷開連接。表現出來的現象就是“后登錄的操作員，由于擁有正確的cookie，而把前一個操作員踢出系統”。

（2）該操作員尚未連接到CS
如果操作員尚未連接到CS，那么登錄請求無論是否帶cookie都都會被接受。需要提醒的是，交易日第一次登錄的時候，可能會把前一日的cookie通過登錄請求傳后后臺，即登錄請求帶錯誤的cookie，后臺在該操作員當日從未連接過的情況下不會校驗該值，并且生成新的cookie返回。

考慮到特殊情況，比如登錄響應丟失，那么相當于后臺認為操作員已經登錄，前臺卻未能拿到cookie。因登錄請求沒有響應而超時，EzOES會重復嘗試wanRetry（用戶配置參數）次，這類情形無需人工干預。

在對市場發布的EzOES缺省配置中，設置不把cookie保存到本地文件，cookie內容僅存在于內存中。之所以這樣配置不把Cookie寫入磁盤的原因是：新交易系統中設計了前臺和后臺之間的雙向心跳，原來經常使用的吧Cookie寫入磁盤并復制到其他機器上，以支持在報盤機故障后，能夠自行恢復登錄的方法，已經不是很有必要性了。EzOES保留寫入磁盤的參數配置的功能，只是為了提供“兼容性”。

在防重復登錄機制發揮作用時，如果不考慮“心跳”機制，那么在某些特殊情況下，可能發生：前一次登錄處于“僵死狀態”不能正常工作，而后續登錄被拒絕的場景。這樣的場景對用戶安全運行有很大威脅。

新交易系統為防范這種風險，通過EzOES和CS之間的如下互動邏輯，系統實現了雙向心跳機制：

1）EzOES的每個操作員要在連接空閑時定時（4秒鐘）向CS發送連接檢查消息。若CS長時間既沒有收到EzOES的業務消息，也沒有收到連接檢查消息，CS會斷開與EzOES之間的連接，此時EzOES會根據操作員的狀態進行不同的處理：如果操作員在正常運行狀態，系統會進行重新連接，該過程同“登錄過程”；如果操作員不在正常運行狀態，如正在初始化、正在登錄或正在注銷等狀態，則系統自動將該操作員注銷。此處重連加上狀態條件是為了避免在CS異常情況下連上去就被斷開會造成死循環。

2）為快速檢測到鏈路故障，CS也對EzOES心跳進行回應。CS在10倍的心跳間隔CsRdrTimeOut（心跳間隔為4秒鐘）內如果還沒能給出消息回應，則EzOES斷開連接并認為連接異常進行相應的處理。

由于心跳機制的實現，在處理操作員注銷操作時，EzOES向后臺發送操作員注銷請求，但是無論響應成功還是失敗，均退出操作員并斷開連接。且注銷的時候同時清除內存中的操作員密碼。

四、成交回報推送以及重傳機制
為縮短市場參與者拿到成交回報的延時，新交易系統實現“成交回報推送”的機制，也就是說訂單在后臺一旦撮合成功，即刻從后臺向前臺送出成交回報。同時，由于成交回報在傳輸過程中可能的丟失，或者前臺由于各種特殊需要而需要從后臺重新拿到成交，系統也同時實現“成交回報重傳”機制。

新交易系統提供“可擴展性”，其一個基本原則是對各個產品的交易撮合不再集中在一臺設備上進行，而是按照若干個產品集SET分布在不同的交易主機上。所以下文中會反復提到產品集SET的概念。

與處理操作員登錄不同，新交易系統在處理成交數據流時，是按照“交易單元”來管理的。為實現“成交回報推送以及重傳機制”，除了業務上標識成交的唯一編號：成交編號tradeNo之外（對于同一個成交編號，同一次成交有兩條數據，分別對應買方和賣方），另外提供了廣播序號seqNo，這是交易系統后臺針對每個交易單元和產品集的同一類型私有廣播（如成交確認）進行的編號，對于一個交易單元一個產品集該序號從1開始，連續遞增。前臺需要“成交回報重傳”時，也需要根據該廣播序號向后臺發出請求。

在原有市場參與者接口表3中有兩個字段：gdxm和bcye。在2002年中國結算公司成立之后，由于交易業務中gdxm不是必要字段，從而中國結算不再向交易系統提供股東姓名的更新數據，故交易系統中的gdxm字段不再更新；而bcye字段存放本次成交后賬戶余額。為避免接口表在系統上線時的大調整，EzOES把產品集SET號和變換后的廣播序號seqNo，分別寫入gdxm和bcye字段，其中bcye字段中寫入的值是原廣播序號的10倍（這樣就能在ETF等需要映射成多條記錄時通過加上個位數來防止重復）。

成交確認只有一種恢復方式，即恢復表3尾部丟失的成交回報。對從表3中間刪除若干成交回報的情形，EzOES不予恢復。對于表3全部清除的情形，EzOES直接向后臺請求重發所有SET上的所有成交。表3非全部清除情況下考慮到成交回報的廣播序號（seqNo）只在SET內部連續，恢復成交回報必須通過查詢數據庫獲得成交確認表中記錄的每個set的最大廣播序號。如果某個或某些SET在數據庫中沒有成交，則EzOES會從seqNo=1開始恢復。

為降低對數據庫訪問的壓力，在處理成交回報時，采用緩沖機制。EzOES對每個SET都設置相應的“缺口填補隊列”，該隊列保存已經收到（包括重傳）的序號不連續的成交確認數據，隊列最大長度為10000。若“缺口填補隊列”中序號連續且沒有缺口，則寫入數據庫接口表。若EzOES發現有缺口（序號不連續）并且進行“消息檢查”時發現當前消息的序號大于當前隊列所能夠存放的序號，則丟棄該數據，該數據將在后續的成交確認恢復過程中進行恢復。

此外，為避免大規模重傳給后臺帶來的壓力，重傳請求的范圍會被分割，其分割單位(BATCH_SIZE)為可配置（缺省值為45，因為每個數據包（最大為4K）所能傳輸的成交數量為最多為45條，EzOES要求該值不能大于360，否則取最大值360），即如果需要重傳10000條成交回報，EzOES會依次發出10000/BATCH_SIZE +1條異步的成交回報重傳請求。為避免“并發”的重傳請求太多，必須等上一個重傳請求的成交全部收到后才會發送下一個重傳請求。

此外，因成交的重傳是靠發現缺口來驅動，如果每個SET最后若干條成交回報丟失則無法發現。對此系統設計了兩個機制：一是后臺系統在閉市后，為每個SET發送一個流結束EOS消息，EzOES在收到所有SET的流結術消息后，確認無缺口，并提示成交回報接收完畢。二是當連續2分鐘沒有收到成交，則去比較本地已經收到的最大成交序號和后臺最新成交序號，若有gap則進行重傳。直到所有EOS收到為止。

如果登錄時候發現需要恢復的成交數量較大（超過10000條，此值可配置）則彈出提示框，提示選擇是繼續收新來的成交還是開始恢復丟失的成交。

需要特別說明的是，采用“成交回報推送”機制后，可以想象，相對后臺系統的強勁處理能力，前臺報盤機的處理能力太弱了，如果在后臺發生大量成交瞬時生成，成交回報瞬時推送到前臺，很有可能頃刻間打垮前臺接口數據庫等。為此，EzOES在插入寫數據庫的隊列時，檢查該寫隊列的大小，當該隊列大于閥值，控制讀數據庫的功能和從后臺取成交回報的功能暫停。這樣控制的目的是，保證系統不在壓力過大的前提下崩潰，而是通過暫停產生新壓力的原則，使得壓力逐漸被“消化”。

五、獨立日歷以及前后臺時鐘同步機制
在市場創新業務推出前，經常需要組織測試，而完成一個完整的業務，常常需要在一個日歷日內安排多個交易日的仿真。在過去，這樣的測試需要通過修改計算機設備的系統時鐘來進行，而這樣的調整往往蘊含著比較大的操作風險。因此，為降低測試帶來的風險，新交易系統實現了一種稱為“獨立日歷”的機制，即應用本身的“日歷”可以和系統設備的“日歷”獨立。應用在獲取時間的時候，是通過把自身的維護的一個日期數據與通過系統調用返回的時間數據，組合之后作為應用采用的時間來使用。這樣的設計，使得機器設備的日期和業務應用的日期相互獨立，提供了必要的靈活性。

在新交易系統數據中心內部，通過高等級的原子種和標準的NTP服務，保證所有交易主機、CS等設備的系統時鐘均同步到一個標準時間上。而與此同時，市場參與者的柜臺系統普遍需要和上交所后臺系統進行對時。

新交易系統提供兩種方式來支持市場需求，一是在CS上對外開放NTP服務，市場參與者可以在報盤機上配置NTP客戶端，或者使用上交所提供的EzNTP程序，控制對報盤機的系統時鐘進行與后臺的同步。二是EzOES程序自行維護報盤機時鐘與后臺時鐘的差異，應用程序使用后臺時鐘，而不是前臺時鐘。通過這樣兩種支持方式，市場參與者可以選擇EzOES在日常運行的時候，不使用Administrator或者root這樣的超級用戶，極大地降低安全方面的風險。

下文介紹EzOES維護時鐘的原理。這個原理實際上和NTP原理相類似，都是基于一個網絡中，兩個節點之間的消息傳輸，在往來鏈路上所耗費的時間基本相等的假設，通過采取時間差的方式獲得前后臺的時間誤差。為準確描述，采用如下形式化語言來說明：

第一步，EzOES發請求,其中記錄前臺當前時間t1????
第二步，后臺收到前臺請求,立刻記錄CS當前時間t2
第三步，后臺在響應中復制t1和t2，在CS發出該響應消息的時候記錄CS當前時間t3
第四步，EzOES收到響應,記錄前臺當前時間t4

EzOES循環進行以上4步動作，每次之間的間隔是2分鐘，所以如果絕對值t4-t1>2分鐘或者t4-t1<0，表示本次和后臺的交互耗費時間太長或者在交互過程中本地時間被調整過，則認為該次軟時鐘維護無效。

消息在上下行鏈路上所花費的時間為 ((t4-t1)-(t3-t2))/2

timegap是前臺時間和后臺時間的差額，計算方法為
timegap = t2 - (t1+((t4-t1)-(t3-t2))/2) = （t2+t3-t1-t4）/2

如果timegap<0，說明報盤機時鐘比后臺時鐘快
如果timegap>0，說明報盤機時鐘比后臺時鐘慢
如果timegap=0，說明報盤機時鐘比后臺時鐘同步

該timegap一直保存在內存中。后臺時間即本地時間+timegap。

如果在發送時間同步請求卻尚未收到響應的時刻修改本地時間，則會造成錯誤的計算結果，該時間錯亂在2分鐘后的下一輪時間同步會予以修正。故市場參與者在正常運行過程中，不要調整系統本地時間。

同時，EzOES也順便利用時間同步邏輯，完成“短消息”的功能。短消息的最大程度為200字節，如果消息內容不為空，EzOES會將其顯示在報盤機界面和狀態文件。該消息EzOES不做歷史存儲，只是直接顯示當次時間同步中獲得的短消息內容。

六、后臺防重單以及前臺斷網重連機制
新交易系統后臺作了重大改進，系統確保同一個訂單不會被重復處理。基本原理就是后臺把一個產品集內“業務單元+券商訂單號”作為定位訂單唯一的關鍵字，當后臺再次收到以前曾經收到過的相同一個關鍵字的訂單時，不會將其進當作一個新訂單來處理，而是將以前的處理結果返回給前臺。這種后臺防重單機制的實現，大大簡化了前臺的邏輯。前臺子系統內部處理各種異常簡化為一種方法：“重發”。

在新交易系統繼承和兼容原有的SQL數據庫接口中，券商訂單號的取值是采用記錄順序號rec_num。在切換后推出的STEP協議接口中，將不再保留記錄順序順序號rec_num，統一采用唯一的券商訂單號（也被稱為Reff），以簡化市場參與者柜臺系統的設計。

由于EzOES部署在市場參與者的數據中心，通過廣域網與交易所數據中心連通，而廣域網發生中斷的概率較高。為提高系統的易用性和自動化程度，當EzOES檢測到廣域網中斷后，會自動通過備用鏈路重連。

重連的核心原理是：EzOES在預先配置的備用鏈路組合（CS IP，LocalIP）上重新執行登錄過程。該過程和正常情況下的登錄是大體是相同的，唯一的區別在于重連之后會把內存中的未收到響應的訂單重發，而手工登錄則會清除內存中的未收到響應的訂單數據。

七、滑動窗口以及流速權控制
EzOES使用了一種在網絡底層協議中廣泛使用“滑動窗口”流控技術。EzOES控制當未確認的訂單數目達到窗口上限時暫停發送。示例如下，假設窗口大小為5，需要發送編號從1到20的訂單，首先EzOES發送1到5，達到窗口上限，暫停發送；當后臺返回x個確認，則EzOES馬上再發送編號為6，...，6+x訂單，使得再次到達窗口上限，等待進一步的確認返回。總之，是一種“異步”的方式在處理。

但是對于一些特殊的場景，出于控制SQL接口表中相鄰訂單順序申報的理由，滑動窗口的大小需要控制為1，使得前臺在一筆訂單向后臺發送之后，只有等待后臺對該筆訂單的響應回來之后，才向后臺發送下一筆訂單。目前，采用這種同步發單的場景有：后臺返回響應說明交易時間表還未到、處于交易時段轉換期、后臺遇到Failover等純技術因素拒單時。

經常有市場參與者咨詢如何“搶到集合競價階段的第一筆訂單？”，那么集合競價開始之前EzOES究竟采用何種方式向后臺申報委托呢？下文概述之：
1）EzOES在登錄成功后，會從后臺獲取到當日交易時間表，確定何時進行交易時段的轉換，比如從開市前時段轉換到集合競價時段。
2）在交易時段轉換之前，EzOES采用同步方式報單，即向后臺發出一單之后，需要等待這一個訂單確認返回后，才進行后續處理。這也被我們稱為“敲門機制”。過程是當訂單從EzOES發出，經過廣域網傳輸到達后臺后，如果后臺還未開市，則訂單被拒絕，且其錯誤代碼標明后臺尚未開市。EzOES根據這個錯誤代碼，睡眠50毫秒后重新發送該訂單，直到該訂單被后臺接收。
3）當訂單被后臺接收后，EzOES則轉換入異步的滑動窗口方式報單。

從這個過程可以看出，“去得早不如去得巧”，如果訂單發出得早，而后臺尚未開市，則需要下一個周期才能再次嘗試；而很可能另外一個報盤機，訂單發出的稍晚幾個毫秒，但是恰好后臺剛剛開市，即刻就進入后臺。但是，這個也是公平的，由于屬于“隨機”分布的，每個報盤機都有相同的概率，從長期運行的情況來看，獲得排名第一筆訂單的次數是基本一致的。

EzOES對流速的控制通過限定滑動窗口的大小來實現。限速值在后臺設置，該值的計算公式為：限速值（QSize）＝ PBU流速權×發單系數×鏈路系數。其中“發單系數”是一個常量，與用戶和鏈路無關。“發單系數”目前取值為20。鏈路系數顧名思義是根據鏈路類型的不同而取值不同。由于不同鏈路上的訂單平均響應時間不同，鏈路系數的設置是為了保證相同的流速權的用戶在不同鏈路上有相同的報單速度。也就是說對于響應時間比較長的鏈路，交易所后臺會給出更大的QSize。目前后臺對衛星鏈路配置為5，對地面鏈路配置為1。

PBU的流速權值會在報盤程序界面上顯示。通常情況下流速權的配置值為1-10。EzOES報單速度的近似計算公式如下：報單速度 = QSize／訂單平均響應時間。如果訂單平均響應時間為0.2秒，最大在途訂單量QSize為20，則1個流速權報單速度約為100筆/秒。

轉載于:https://www.cnblogs.com/timlong/p/6933616.html

總結

以上是生活随笔為你收集整理的交易系统解析(六)前台报盘应用设计要点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。