Capital外期行情資訊架構分析(Pats)

張貼日期：Feb 28, 2011 12:51:14 PM

現行架構

[Gateway] ---> [接收層] ---> [應用層] ---> [用戶端]

[接收層] :

(轉碼程式) ---> (INSKW) : 提供[應用層]連線註冊與回補

(轉碼程式) : 提供(INSKW)連線接收<RAWDATAFORMAT>, 目前除(INSKW)之外無任何其它應用程式使用轉碼程式提供之資訊

(INSKW) 的工作

1.將<RAWDATAFORMAT>逐筆儲存成Log,並提供作為[應用層]回補的來源。

2.將<RAWDATAFORMAT>轉成[應用層]所需格式並發送,同時依商品別轉成<TICK>格式作存檔。

(INSKW) 的問題

程式設計上，清盤必須要先將程式關閉，關閉時進行換日的工作，過程中需要寫檔、檔案搬移等處理，程式再重新透過排程執行，完成換日清盤。

這樣的程序造成有一些問題，如果檔案沒有正常清掉，清盤就會出問題，可能導致無法順利開盤等狀況。

目前需要先改善這一層的架構，可以不用關閉程式完成換交易日清盤的處理。

其次，程式的效能不太好，Tick累積在記憶體中，會超過4G的限制，須將商品拆分由不同的(INSKW)來處理，架構變複雜。

然後是K線的轉檔程式問題，由另一台轉檔主機將(INSKW)產生的today檔，進行技術分析的轉檔處理轉成文字檔，

再透過另一支程式匯進資料庫，及由另一支程式產生技術分析相關歷史線圖，過程也常因為異常，導致轉檔失敗，造成 K線資料的異常。

GMDS的架構方式#1

儘可能維持群益現行資訊架構的完整性,從最源端處理取代

[GMDS] ---> [接收層] ---> [應用層] ---> [用戶端]

[接收層] :

(INSKW) : 自行轉碼並提供[應用層]連線註冊與回補

(INSKW) 的工作

1.透過GMDS's API接收行情並透過Quote-Manager產生一份Quote Memory含有<RAWDATAFORMAT>結構與所有需要的資料狀態。

   ( 可以參考 Quote-Manager for Capital INSKW )

2.將<RAWDATAFORMAT>逐筆儲存成Log,並提供作為[應用層]回補的來源。

3.將<RAWDATAFORMAT>轉成[應用層]所需格式並發送,同時依商品別轉成<TICK>格式作存檔。

(INSKW) 問題的分析

清盤的問題主要是因為Tick檔存放在固定的資料夾下,因此換日時希望將Tick搬移到其它資料夾保存並將該固定資料夾清空,

其次因為K線轉檔程式將轉出之today檔也放在Tick資料夾內,當清盤的搬檔刪檔出問題時,轉檔也會錯誤,

而如果K線轉檔程式於清盤處理時仍開住Tick檔或today檔,勢必影響(INSKW)的搬檔刪檔因而失敗,

同樣today檔的部份包括匯入資料庫的程式如果仍開住檔案,也是一樣會影響到(INSKW)的清盤處理。

記憶體限制上的問題,主要是Tick累積保存在記憶體是否有意義? 另外是否可能是因為BCB的AnsiString這物件本身設計不良所導致。

(INSKW) 改善的方式

清盤的問題可將Tick依交易日分存於不同資料夾下,即可免除搬檔刪檔之動作,新的交易日於新的資料夾內存檔則不會有檔案沒清掉的問題,

影響的部份是相關轉檔與轉資料庫的程式須一並修改成依據交易日處理對應的資料夾。

記憶體的部份,Tick無需以LIST存放累積於記憶體,可於存檔後即由記憶體中移除,當下游須回補時改透過由檔案來提供。

BCB的AnsiString這物件需用特別的技巧來使用,避免造成記憶體匱乏。

GMDS的架構方式#2

在與GMDS的架構方式#1並存的方式下，同時能考慮跳過[接收層]的應用設計方式

[GMDS] ---> [接收層] ---> [應用層] ---> [用戶端]

[GMDS] ---> [應用層] ---> [用戶端]

[接收層] :

(INSKW) : 自行轉碼並提供[應用層]連線註冊與回補 (同GMDS的架構方式#1)

[應用層] :

(INSAPP) : 自行轉碼並提供[用戶端]連線註冊與回補(類似INSKW的設計)

(INSAPP) 的工作

1. 透過GMDS's API接收行情並透過Quote-Manager產生一份Quote Memory含有(INSKW)提供之行情結構與所有需要的資料狀態。

2. 除接收行情的部分由[接收層]改為[GMDS]以外,所有原本的工作維持不變。

(INSKW) 的工作可由GMDS取代

1. 由於GMDS上也能自行儲存Tick與轉K線,所以能替代掉原(INSKW)的相關功能。

2. 透過GMDS的TSHS服務,(INSAPP)接收的是無中斷的連續行情資訊服務,所以已無回補問題。

3. 無須拆分商品由多台主機分工,(INSAPP)一個連線即可接收所有商品行情。

設計方式

[接收層]的設計可以過GMDS的DbfTS資訊架構來進行,也可以透過TSHS的資訊架構來進行。

[應用層]的設計直接透過TSHS的資訊架構來進行。

可以參考 TSHS (Tag Sream History Server) , DbfTS

新舊架構差異性

1. 新架構是有異動才更新的資料傳輸方式並使用壓縮處理,舊架構是使用固定結構大小也無壓縮功能,

    因此傳輸資料量大為減少,頻寬使用上的差異會更明顯。

2. GMDS/TSHS的架構提供的不僅是回補,也具備遠端重新建置的需求,不僅可取代原[接收層],

    對於跨日,清盤,商品開收時間差異性等問題提供更具彈性的設計選擇與處理方式。

GMDS/TSHS對群益的意義

針對已知的群益問題,提供多種解決方向與方式。

針對現況只要介接的概念與設計方式正確,所有問題已不具威脅性。

解決方向與方式

1. [接收層] INSKW以 PktEvCdll API 介接TSHS,取代原本Socket連接轉碼程式。

2. [應用層] INSAPP以 PktEvCdll API 介接TSHS,取代原本Socket連接[接收層]INSKW。

3. [接收層] 轉碼程式與INSKW之間的通訊,建立TSHS或說是RSHS(Raw Stream History Server)。

4. [應用層] INSAPP與[接收層]INSKW之間的通訊,建立TSHS或說是PSHS(Packet Stream History Server)。

5. 於1.與2.所描述的TSHS,可以是GMDS的輸出或是3.與4.所描述的群益現行格式輸出。

問題與威脅

1. 清盤問題, 於清盤時間檢查,若有狀況可把程式down下來,人工處理後程式從資訊斷點啟動資料不會遺漏

    ,或回溯某一整點區間啟動進行盤前資料重建(可參考 TSHS (Tag Sream History Server) 第11.點)。

2. Tick/記憶體問題, 可以每四小時或更短時間, 透過程式重開釋放記憶體再從資訊斷點啟動資料不會遺漏。

3. 轉檔程式問題,其實是清盤問題所產生,當清盤經過妥善處理,狀況自然解除。

當然, 這些是治標, 緩解現狀所面臨的問題從而換取時間對症下藥, 以所建議的改善方式從根本解決問題,

並妥善安排規劃符合群益未來各種可能性需求的架構與產品。

回歸源端再分析

倘若[接收層]僅僅是一部PC,就沒有再次分析的必要,但依據已掌握的系統癥結與問題點重新判斷,

[接收層]如果有轉碼程式和INSKW,而INSKW因為各種問題必須兩套以上的分工理由下,

為避免互相造成影響,估計上 必須是轉碼程式與個別INSKW皆分開在不同的PC上運作才是,

因此以觀察過的結論來看,轉碼程式以極大的資料傳輸量透過網路同時傳輸多份相同資料給多個INSKW,

而INSKW接收完整的資料卻僅篩選有被設定要處理的商品而已

最初提及將系統移轉入GMDS架構下的最快切入點為針對使用PATS's API的程式作修改,

原因為GMDS能提供的資訊跟PATS完全相同,卻更容易設計與使用,目前這個程式應該可以推測就是轉碼程式,

而群益資訊系統最初產生而存在的格式RAWDATAFORMAT也是從轉碼程式開始出來,

轉碼程式將每筆Tick/Price皆以相同的RAWDATAFORMAT格式送出, 長度是 721Bytes再加上 \x0D \x0A 2Bytes共 723Bytes,

再看群益的PATS資訊系統架構圖比對INSKW資訊來源Port為6803,似乎轉碼程式是在Gateway那一層,

如此GMDS可以提供一個可支援群益RAWDATAFORMAT架構,

由GMDS上的TcpRDS接收RAWDATAFORMAT,並改以TSHS服務,針對INSKW則不需自行轉碼,且透過TSHS接收原本接收的格式即可

這樣頻寬負載至少可減低至原本的30%以下,且同時也具有相當於回補的功能,相信修改的工程也更相對簡化

最後一個問題是,系統怎樣才算是接在GMDS上呢?

目前GMDS可提供的方式包括INSAPP直接連GMDS, INSKW直接連GMDS, 同時於TSHS的服務下相當於皆有回補的功能,

倘若可行的話轉碼程式或INSKW可以直接被替換掉而不需要存在,也代表系統已接在GMDS系統下

另一個方式便是這邊所提的TcpRDS/TSHS的方式介接,同時也將轉碼程式改成使用GMDS的API接收PATS資訊於GMDS上運行,

如此雖然需修改轉碼程式和INSKW但是都是相對容易的工程,可以最快完成,以此方式系統便完全接在GMDS系統之下了

TSHS 支援TFS系列資訊系統

可參考 RawData資訊架構

A) 資訊源為Multicast的架構方式.

    (適用範圍: TSE, OTC, TFE, Systex F1 ).

B) 資訊源為TCP Socket的架構方式.

    (適用範圍: Abula MPX, ComStock RTU/DataHub, Shanghai Gaoying DS, Systex IX, SSE/SZSE VDE STEP/FAST

                    , Kway MDS, Capital RAWDATAFORMAT ).

C) 資訊源為DDE Server的架構方式.

    (適用範圍: XQ|Quote, DynQuote|IX, EXCEL, 任何符合前述DDE規格的DDE Server資訊來源 )

示意圖:

程式範例: