‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
5、MariaDB 版本:10.0 6、HeidiSQL 版本:8.3.0
4.2、模擬情境
啟動由 VMWare 所虛擬的 3 台主機，經由 Order Enumulator、MOM Enumulator 及 Exchange Enumulator 的操作，分別模擬『資料共享』、『訊息同步』、『程序監控』及『主 機遴選』所發生的情況。
4.2.1、資料共享
說明：在第一章及 3.2.1 節有探討，資料共享在電子交易系統的應用方面，是要產生一 個全域的流水序號，因此不論委託下單至哪一台主機，流水序號應該都是要續編。
模擬方式：MOM Emulator 有主機選擇區，見圖 4.1
圖 4.1MOM Emulator 交易主機選擇區
在下單委託之前，可以選擇要下單至哪一台交易主機，交易主機選定後執行下單交易。
預計結果：Exchange Enumlator 有一個交易序號的欄位，預計在切換交易主機後的每筆 委託之交易序號均能續編。
模擬結果：在分別從 192.168.112.131、192.168.112.134、192.168.112.135
執行下單委託後，可以從 Exchange Enumlator 的交易序號欄位看到交易序號分別是 00000511、00000512、00000513，見如圖 4.2 所示，模擬結果符合預期。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 4.2 交易序號續編
4.2.2、訊息同步
說明：訊息同步代表不論從任何一台主機委託下單，每一台主機都必須要有相同的委託 資料。
模擬方式：MOM Emulator 有主機選擇區，見圖 4.1。在下單委託之前，可以選擇要下單 至哪一台交易主機，交易主機選定後執行下單交易，每台主機委託 3 筆委託，3 台主機 共 9 筆委託。
預計結果：Order Emulator 的『查詢區』，可以針對各主機資料庫進行委託之查詢，如圖 4.2 所示。預計在任何一台主機上，都可以查出分別在 3 台不同主機所下之委託資料。
驗證委託資料的欄位為交易序號單號。
圖 4.3 Order Emulator 查詢區
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
模擬結果：分別從 192.168.112.131、192.168.112.134、192.168.112.135
執行下單委託後，可以從 Order Enumlator 的查詢區查出，不論是哪一台主機，其交易 序號都有從 00000515~00000523 的委託資料，符合預期結果。如圖 4.4 至圖 4.6 所示。
圖 4.4 主機 192.168.112.131 查詢區
圖 4.5 主機 192.168.112.134 查詢區
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 4.6 主機 192.168.112.135 查詢區
4.2.3、程序監控
說明：當某一台主機的處理程序發生異常，其他主機必須被通知有該狀況的發生，並且 要有主機負責該異常主機後續之委託處理。
模擬方式：Order Emulator 有傳送異常訊息的功能，見圖 4.7。
圖 4.7 Order Emulator 傳送異常訊息之檢核框
該檢核框打勾後的委託，在主機端收到後，會產生一個處理程序異常的狀況。委託經選 定下單至主機 192.168.112.131，如圖 4.7。
圖 4.8 選定 192.168.112.131 為交易主機
但因 192.168.112.131 發生處理程序異常，192.168.112.134(跟後續即將討論的 Leader election 有關)接手後續之委託處理。
預計結果：
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
1、在 Order Emulator 可以看到該筆委託之委託回報。換言之，即使在原下單主機之處 理程序發生異常的情況下，該筆委託仍能獲得其他主機接手處理，並收到委託回報。
2、在資料庫看到下單主機 ip 的欄位是 192.168.112.134。而非原下單主機 192.168.112.131。
模擬結果：
1、在 Order Emulator 可以看到該筆委託之委託回報，交易序號為 00000528。表示該筆 委託雖然在原交易主機發生處理程序異常的情況下，仍能完成交易的程序。
2、資料庫中針對交易序號為 00000528 的委託，所顯示的下單主機欄位 HOSTIP 為 192.168.112.134，而非原下單主機 192.168.112.131。
模擬結果均符合預期結果。
圖 4.9 Order Emulator 傳送異常訊息
圖 4.10 委託單之下單主機資訊
4.2.4、主機遴選
說明：要求-回覆(request-response)模式的通訊方式，並不適用於有推播(push)機制的電子 交易系統。原因在於這類的電子交易系統，要求和回覆是可以分屬於不同的通道(channel)，
因此，即便是系統內沒有任何一台主機收到使用者發出的要求訊息，但仍然都會收到來 自於其他通道發出要求後的外部回覆。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
模擬方式：在 Exchange Emulator 有一『外部單模擬區』，見圖 4.11。
圖 4.11 外部單模擬區
這就是在模擬另一個下單的通道。將股票代碼、價格、張數、買賣別輸入完畢後，按下
『回報送出』，及代表另一個通道已完成委託下單。
預計結果：
1、沒有主機遴選機制：Order Emulator 不會呈現不是由 Order Emulator 所交易的委託。
2、有主機遴選機制：Order Emulator 可以呈現非由 Order Emulator 所交易的委託。
模擬結果：
1、主機在沒有啟動主機遴選的情況下(見圖 4.12)，Exchange Emulator 交易兩筆委託，
交易序號分別為 EE163601 和 EE163831，均未在 Order Emulator 中呈現，見圖 4.14。
圖 4.12 主機遴選未啟動
2、主機在啟動主機遴選的情況下(見圖 4.13) ，Exchange Emulator 交易一筆委託，交易 序號為 EE164054，已能在 Order Emulator 中呈現，見圖 4.14 紅框處。
模擬結果均符合預期結果。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 4.13 主機遴選已啟動
圖 4.14 外部單交易及回報結果
‧
更確定該系統的可行性。基於 Zookeeper 服務的對稱式高可靠度電子交易系統於是孕育 而生。 sigma)為例，即便達到 6 sigma，即便不符標準的情況，只有百萬分之 3.4[19]，幾乎趨近 於 0，但不符標準的情況，仍然存在。因此任何跟提高系統可靠度的議題，都是未來可 以研究的方向。