基於Zookeeper服務的對稱式高可靠度電子交易系統架構 - 政大學術集成

全文

(1)國立政治大學資訊科學系 Department of Computer Science National Chengchi University. 碩士論文. 大學. ‧ 國. 立. Master’s 政治Thesis. 基於 Zookeeper 服務的對稱式高可靠度電子交易系統架構. ‧. io. sit. Electronic Trading System. er. Nat. y. Symmetric and High-Available. n. a l Base on Zookeeperi v n Ch U engchi 研究生：常澤民指導教授：陳. 恭. 中華民國一百三年十二月 December 2014. I.

(2) 基於 Zookeeper 服務的對稱式高可靠度電子交易系統架構 Symmetric and High-Available Electronic Trading System Base on Zookeeper 研究生：常澤民恭. 國立政治大學. 學. ‧ 國. 立. Chen 政治Advisor：Kung 大資訊科學系. ‧. Nat. y. 碩士論文 A Thesis. er. io. sit. 指導教授：陳. Student：Tse-Min Chang. submitted ato Department of Computer Science. n. iv l C n U h eChengchi National n g c h i University. in partial fulfillment of the Requirements for the degree of Master in Computer Science 中華民國一百三年十二月 December 2014 II.

(3) 基於 Zookeeper 服務的對稱式高可靠度電子交易系統架構. 摘要隨著電子商務的蓬勃發展，不論是使用者或是服務提供者，對於系統的可靠度(reliability)，越來越為重視，從『能提供服務就好』，到要能提供『不間斷的服務』。這中間的轉變，. 治政推動了目前許多系統架構或產品運用在電子商務的領域。小從磁碟陣列(RAID)、資料庫大立鏡像(Database Mirror)、叢集(Cluster)架構，異地備援(Disaster Recovery Site)，大到企業 ‧ 國. 學. 永續運作計畫(Business Continuity Planning-BCP)的一環，都在尋求一個高可靠度的電子. ‧. 交易系統。. 所謂高可靠度的系統，必須能夠在相對長的時間週期內，系統可以持續運作而不中. y. Nat. io. sit. 斷，這個概念，同時也意味著系統異常時的恢復能力，以及容錯的機制。換句話說，就. n. al. er. 是當系統面臨異常或是災害發生時，如何能在最短的時間內恢復系統的正常運作，繼續. Ch. i n U. v. 提供使用者相同的服務。因此提高系統的可靠度，對使用者的具體意義而言，即是提高其服務的可用度(availability)。. engchi. 本論文的研究，即運用 Apache 下自由軟體 Zookeeper 所提供的協調服務，設計一套透過傳播監控(propagation monitor)來達到容錯機制的對稱式多主機架構，使得系統即使在面對異常狀況發生時，仍能迅速恢復系統應有的功能，提供使用者不間斷的服務。並且利用免費的資料庫管理軟體-MariaDB 來儲存及操作資料，以低廉的成本，建置具高可靠度的電子交易系統。. I.

(4) 關鍵字：可靠度、可用度、容錯、Apache Zookeeper、電子交易、協調服務. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. II. i n U. v.

(5) Symmetric and High-Available Electronic Trading System Base on Zookeeper Abstract Due to the blooming development of electronic commerce (E-Commerce) , both users and service providers put more and more emphasis on system reliability. Thus uninterrupted service has become the basic requirement of E-Commerce systems, which now have all. 政治大. adopted some highly avaialable system architectures and advanced products such as. 立. Redundant Array of Independent Disks (RAID), Database Mirror, Cluster architecture,. ‧ 國. 學. Disaster Recovery Site(DR Site). Many E-Commerce vendors also prepare Business Continuity Planning(BCP) for a highly reliable electronic trading system.. ‧. The so-called high reliability systems must continue to operate without interruption in a. y. Nat. sit. relatively long period of time, and this concept also means the requirements of abnormal. n. al. er. io. system resilience and the mechanism of fault tolerance. In other words, when the system is. i n U. v. confronted with abnormal situations or disaster occurs, it is critical about how to restore the. Ch. engchi. normal functioning of the system to continue to provide users with the same level of services in the shortest possible time, thereby increasing the reliability of the system in terms of the user's specific meaning, that is, to improve its service availability. This thesis applies the coordination service provided by Zookeeper to develop a propagation monitor mechanism and a symmetrical multi-host fault-tolerant system architecture, making the system work even in the face of an abnormal situation. Indeed, the system should be able to quickly restore its functions, providing users uninterrupted service. Besides, we use the free database management software-MariaDB to store and operate the system data. Therefore, we are able to build a low-cost yet highly available electronic trading III.

(6) system.. Keywords：reliability、availability、fault-tolerant、Apache Zookeeper、electronic commerce、 coordination service. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. IV. i n U. v.

(7) 誌謝. 在本論文完成之際，首先要感謝的就是我的指導老師. 陳恭教授。在研究的過程. 中，我因為研究的興趣而改變過許多次的研究方向，老師都能不厭其煩地提供給我我所需要的資料，即便在我休學的期間，仍願意利用假日的時間與我一同討論研究的內容以及論文的進度。而課堂上的授課內容以及觀念的啟發，更延續了我對技術的熱愛。同時，. 政治大. 也要感謝我家人的支持，包容我將原本就不大的書房，建置成小型機房，以順利進行測. 立. 試，完成本論文。. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. V. i n U. v.

(8) 目錄第一章緒論 .............................................................................................................................. 1 1.1、研究背景 ................................................................................................................... 1 1.2、研究動機 ................................................................................................................... 2 1.3、研究目標 ................................................................................................................... 7 1.4、研究成果 ................................................................................................................... 7 1.5、論文之限制 ............................................................................................................... 8 第二章相關研究與技術背景 ................................................................................................ 10 2.1、分散式系統的硬體概念(Hardware concept) ......................................................... 10. 政治大. 2.2、分散式系統的通透性(Transparency) ..................................................................... 10 2.3、主機的協調-Zookeeper 的導入 .............................................................................. 12 2.3.1、Zookeeper 的介紹 ........................................................................................ 12 2.3.2、Zookeeper 的 Data Model ............................................................................ 12 2.3.3、Zookeeper 的 WATCH 機制 ........................................................................ 14 2.3.4、Zookeeper 特性的運用 ................................................................................ 14 2.3.5、基於 Zookeeper 服務下的對稱式系統架構 ............................................... 17 2.4、免費的資料庫軟體-MariaDB[14]........................................................................... 18 2.5、資料庫管理視窗化軟體-HeidiSQL[15] ................................................................. 18. 立. ‧. ‧ 國. 學. sit. y. Nat. n. al. er. io. 第三章系統架構及組件之設計 ............................................................................................ 20 3.1、對稱式系統架構之設計 ......................................................................................... 20 3.2、系統組件之設計 ..................................................................................................... 21 3.2.1、Zookeeper Znode 的階層結構及建立模式 ................................................. 21 3.2.2、資料交換格式 .............................................................................................. 27 3.2.3、交易處理程序 .............................................................................................. 30 3.2.4、通訊介面 ...................................................................................................... 33 3.2.5、Zookeeper Wrapper-API............................................................................... 35 3.2.6、模擬器 .......................................................................................................... 37. Ch. engchi. i n U. v. 第四章概念性驗證(Proof of Concept) ................................................................................ 40 4.1、驗證環境 ................................................................................................................. 40 4.2、模擬情境 ................................................................................................................. 41 4.2.1、資料共享 ...................................................................................................... 41 4.2.2、訊息同步 ...................................................................................................... 42 4.2.3、程序監控 ...................................................................................................... 44 4.2.4、主機遴選 ...................................................................................................... 45. VI.

(9) 第五章結論與未來研究方向 ................................................................................................ 48 5.1、結論 ......................................................................................................................... 48 5.2、未來研究方向 ......................................................................................................... 48 參考文獻 .................................................................................................................................. 50. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. VII. i n U. v.

(10) 表目錄表 3.1 電子資料交換訊息格式 ............................................................................................... 27 表 3.2 電子資料交換訊息格式-header .................................................................................. 27 表 3.3 電子資料交換訊息格式-tail ........................................................................................ 28 表 3.4 電子資料交換訊息格式(委託)-body........................................................................... 28 表 3.5 電子資料交換訊息格式(檢核回覆/後台下單/回報)-body ........................................ 29. 圖目錄. 政治大. 圖 1.1 對稱式多處理器系統 ..................................................................................................... 3 圖 1.2 多重主機系統 ................................................................................................................. 3 圖 1.3 對稱式多主機系統架構 ................................................................................................. 4 圖 1.4 對稱式多主機系統面臨的問題-架構圖 ........................................................................ 7 圖 2.1Zookeeper 的階層式命名空間 ..................................................................................... 13 圖 2.2Zookeeper 的目錄內容 ................................................................................................. 13 圖 2.3Propagation monitor .................................................................................................... 16 圖 2.4Leader election .............................................................................................................. 17 圖 2.5 基於 Zookeeper 服務下的對稱式系統 ....................................................................... 18 圖 2.6HeidiSQL 操作介面 ...................................................................................................... 19. 立. ‧. ‧ 國. 學. sit. y. Nat. n. al. er. io. 圖 3.1 基於 Zookeeper 服務的對稱式電子交易系統宏觀架構圖 ....................................... 20. v. 圖 3.2znode 階層架構及其建立模式 ..................................................................................... 22 圖 3.3 主機群與主機的關係圖 ............................................................................................... 25 圖 3.4 程序與主機的關係圖 ................................................................................................... 26 圖 3.5 程序與執行緒的關係圖 ............................................................................................... 27 圖 3.6 電子交易委託流程圖 ................................................................................................... 30 圖 3.7 電子交易回報流程圖 ................................................................................................... 32 圖 3.8Zookeeper Wrapper-ZKLib ........................................................................................ 35 圖 3.9 下單及回報模擬器 ....................................................................................................... 38 圖 3.10MOM(Message Oriented Middleware)模擬器 ........................................................ 38. Ch. engchi. i n U. 圖 3.11 交易所模擬器 ............................................................................................................. 39 圖 4.1MOM Emulator 交易主機選擇區 ............................................................................... 41 圖 4.2 交易序號續編 ............................................................................................................... 42 圖 4.3Order Emulator 查詢區 ............................................................................................... 42 圖 4.4 主機 192.168.112.131 查詢區 ...................................................................................... 43. VIII.

(11) 圖 4.5 主機 192.168.112.134 查詢區 ...................................................................................... 43 圖 4.6 主機 192.168.112.135 查詢區 ...................................................................................... 44 圖 4.7Order Emulator 傳送異常訊息之檢核框 ................................................................... 44 圖 4.8 選定 192.168.112.131 為交易主機 .............................................................................. 44 圖 4.9Order Emulator 傳送異常訊息 ................................................................................... 45 圖 4.10 委託單之下單主機資訊 ............................................................................................. 45 圖 4.11 外部單模擬區 ............................................................................................................. 46 圖 4.12 主機遴選未啟動 ......................................................................................................... 46 圖 4.13 主機遴選已啟動 ......................................................................................................... 47 圖 4.14 外部單交易及回報結果 ............................................................................................. 47. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. IX. i n U. v.

(12) 第一章緒論想像以下 3 個例子： 1、台灣證券交易所暫停交易。 2、網路商城，買家下訂單而賣家卻沒收到訂單。 3、在網路書店購書，卻收到別的客戶訂書。在電子交易活絡的今天，這些例子是不被允許的，甚至會引起交易糾紛。一個被要求一. 政治大. 年停機不超過三分鐘的電子交易網路，99.999%的可靠度仍嫌不足[1]。可見可靠度在電子交易系統的重要性。. 立. ‧ 國. 學. 系統的可靠度，絕對是電子交易系統在設計時的首要考量重點。從備援及容錯移轉的角度來看，Active/Stand by、Active/Passive(Hot standby)、Active/Active，都再再說明，. ‧. 不論是人為的介入或是系統偵測異常時的自動切換，唯一的目的，就是希望當異常發生. Nat. sit. y. 時，仍能盡量保持系統的穩定性，能以最快的速度恢復系統原有的功能，讓災害影響的. 1.1、研究背景. al. n. 有異常狀況的發生。. er. io. 範圍可以縮到最小。最理想的狀況，就是讓使用者在整個使用過程中，根本沒有體驗到. Ch. engchi. i n U. v. 『為什麼不能交易了？』、『我的委託單到哪去了？』、『我買到了沒有？我賣出去了沒有？』，這些不確定的疑問句，絕對是犯了電子交易系統中的大忌：不穩定，換言之，就是不可靠。一個不可靠的系統，比一個效能不佳的系統，更容易讓人望之怯步。效能不佳的系統，最差的情況，只是交易的結果會花久一點的時間回覆給使用者；但不可靠的系統，卻會帶給使用者不知所措的恐懼，因為使用者不知道下一步該如何進行。這種情形，尤其在金融的電子交易領域中更加明顯。試想，以 123 塊的價格來買進 XX 電子 20 張， 1.

(13) 送出的按鈕一按下去，卻遲遲等不到系統的回覆，這代表著，光該筆的交易，基本上就有 246 萬元的委託交易是下落不明的，對使用者來說，能不害怕嗎？因此建立一個高穩定度的電子交易系統的需求，在電子商務蓬勃發展的今天，不斷地被提出來。從資料的一致性，系統異常的監控，到系統異常的容錯移轉，都是一個高穩定度系統必須考量及設計的重點，而環繞在這些設計考量及重點之下，漸漸地，有些新的軟、硬體產品或 infrastructure 的設計，被應用在電子交易領域，磁碟陣列(RAID, Redundant Array of Independent Disks)，資料庫鏡像(Database mirror)，叢集(Cluster)架構，Storage area. 政治大. network(SAN)等等。. 立. 『能提供服務就好』的時代已經過去了，『不間斷的服務』早已成為電子交易系統. ‧ 國. 學. 在市場上生存的必要條件之一。如何能提供『不間斷』的服務？這句話，可以視為，如何能提供『高穩定度』的服務，一個系統穩定度的重要性，可見一般。本論文所提出之. ‧. 對稱式電子交易系統，並非是基於提高複雜運算速度而產生的分散式系統，主要強調的. Nat. sit. n. al. er. io. 1.2、研究動機. y. 重點是『穩定』，而非『速度』。. Ch. engchi. i n U. v. 在探討多處理器(Multiprocessor)的系統時，有一個類型稱之為『對稱式多處理器系統』 [2]。在這類的系統中，各處理器的地位都是平等，擁有同樣的權限可以使用系統資源，處理器之間以匯流排(Bus)緊密連接，而各處理器之間擁有稱為主記憶體(Main memory) 的集中式共享記憶體 (Centrailzed shared Memory) ，處理器之間具有高度的耦合性 (Tightly-coupled)。請見下圖 1.1. 2.

(14) 立. 政治大. ‧ 國. 學圖 1.1 對稱式多處理器系統，本圖取自[3]。. ‧. 但如果將各處理器，分屬於不同的主機上，彼此之間是透過高速網路裝置來傳遞訊. y. Nat. io. sit. 息，沒有共享的主記憶體，各主機擁有獨立的記憶體及 I/O，處理器之間具有低耦合性. n. al. er. (Loosely-coupled)。這類型的多處理系統，又可稱為多重主機(Multicomputers)系統[4]，見圖 1.2。. Ch. engchi. i n U. v. 圖 1.2 多重主機系統，本圖取自[5] 在分散式系統的優點評估中，有一潛在的優點，就是穩定度高[4]。要能提供一個高穩定性的電子交易系統，無疑必須採取分散式的多主機架構，而且，為了考量當主機發. 3.

(15) 生異常時，其他主機接續處理的時間可以最短，因此在設計上，各主機的軟、硬體資源、處理程序是可以呈現『對稱式(symmetric)』的分配。所謂對稱，即讓每一台機器上都『同時』運作相同的處理程序，做相同的事情，儲存同樣的資料，正因為機器之間沒有所謂的主從關係，所以每台機器角色平等，如此一來，即便整個系統的機器群發生異常到只剩下一台機器可以運作，該單一機器仍能繼續提供原有的服務，但如此的設計架構，在負載平衡(Load balance)上，並沒有辦法提供效益，因為每一台機器都有著相同的訊息量。對稱式多主機系統的概觀如圖 1.3 所示. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 1.3 對稱式多主機系統架構圖示說明如下 1、Host1 至 Host N：代表有 1 至 N 台的主機。 2、P0、P1、P2、P3：代表每台機器都有著相同的處理程序 P0 至 P3。 3、D0、D1、D2、D3：代表每台機器都儲存著相同的資料 D0 至 D3。然而一個對稱式的電子交易系統，各主機之間都擁有著獨立的硬體資源(CPU、Local memory/Cache、Disk、BUS、Network)，處理程序，儲存資料，在這樣一個低耦合(loosely 4.

(16) coupling)的架構之下，會面臨到以下的幾個問題須要解決 1、資料共享，避免資料重複整個主機群，只能產生一個不能重複的全域資料，例如全域的流水編號。以流水編號而言，雖然可以用每台機器給一個 leading code 或是指定每台機器的編碼起迄範圍，但都有缺點。leading code 的缺點在於，一個固定編碼長度(一般來說是 8bytes)的流水序號，拿至少 1byte 當 leading code 時，整個可編序號的範圍就少了 10 倍，而指定每台機器的編碼起迄範圍，會有序號浪費或不夠用的問題產生。. 立. 政治大. 2、訊息同步，避免資料的不一致性. ‧ 國. 學. 因為每一台主機都必須擁有相同的資料，因此任何一台機器在收到來自外部的訊息時，都必須將該訊息傳遞給其他的主機，讓其他主機也能針對該訊息做相對應的處理。. ‧. Nat. sit. y. 3、程序監控，避免異常發生時，中斷應有的服務. n. al. er. io. Joe Armstrong 在其著作『Programming Erlang：Software for a Concurrent World』對. i n U. v. 於程序的監控，有如是的說明：『如果有人死掉了，其他人會注意到』[6]。這也就表示，. Ch. engchi. 要有一個當程序或主機發生異常狀況時的通報處理機制。當一台機器發生異常時，系統中的其他主機處理程序，會收到通知，而收到通知的主機，接手該異常主機接下來應該要完成的事情，讓來自於外部的訊息，即使在遇到系統異常的情況下，仍能獲得不間斷的服務。. 4、主機遴選，避免訊息遭丟棄或重複處理要求-回覆(request-response)模式的通訊方式，並不適用於有推播(push)機制的電子交易系統。原因在於這類的電子交易系統，要求和回覆是可以分屬於不同的通道(channel)，因此，即便是系統內沒有任何一台主機收到使用者發出的要求訊息，但仍然都會收到來 5.

(17) 自於其他通道發出要求後的外部回覆。舉例來說，我們的系統為 M，有主機 M 1 至 M n，其他系統為 T，使用者從系統 T 發出一個要求，該要求經過外部處理後的回覆，除了會回覆給系統 T 之外，還會回覆給我們的系統 M 1 至 M n。為什麼會出現這種狀況？原因在於各系統之間要能看到彼此之間的交易內容。問題來了，我們系統的主機有 M 1 至 M n，每一台都收到相同的回覆訊息，如果每一台都往前端推播，則前端會收到 n-1 個重複的回覆，但不推播也不行，因為不推播，前端就不會收到交易結果的回覆。因此系統中只能有一台是負責這類沒有 request，但卻有 response 的推播功能。既然只能有一台，. 政治大. 接下來的問題產生了：要哪一台負責？決定的機制為何？如果這台發生異常，哪一台要. 立. 接手？而這些問題，正是有關主機遴選的議題。. ‧ 國. 學. 綜合上述的說明，可以知道，在對稱式多主機設計的系統架構下，勢必要有協調各主機之間有關『資料共享』、『訊息同步』、『程序監控』及『主機遴選』的運作問題需要. ‧. 解決。如圖 1.4 所示。圖中標示 1 之處，代表要產生全域的流水序號，這跟資料共享有. Nat. sit. y. 關；圖中標示 2 之處，代表訊息在其中一台主機收到後，必須同步到其他主機；圖中標. n. al. er. io. 示 3 之處，代表該如何監控處理程序之異常情況；圖中標示 4 之處，代表當所有主機都. i n U. v. 收到外部訊息的時候，該由哪一台主機負責處理，才不會出現重複處理的問題，這會跟主機遴選有關。. Ch. engchi. 6.

(18) 政治大圖 1.4 對稱式多主機系統面臨的問題-架構圖立. ‧ 國. 學. 除此之外，主機的資料儲存會涉及到資料庫的運用，目前市面上的商用資料庫都所. ‧. 費不貲，如果要建立一台以上的對稱式多主機系統，一台主機就要有一個資料庫，那所有主機加起來的資料庫授權費用更會高得讓人望之怯步，因此在資料庫的選定上，必須. y. Nat. n. al. er. io. 統目標。. sit. 朝向低成本，甚至是免費的資料庫管理系統，如此一來，才能符合高穩定且低成本的系. 1.3、研究目標. Ch. engchi. i n U. v. 以對稱式多主機的架構，設計一套低成本，高可靠度、不間斷服務的電子交易系統是本篇論文的目標。所謂高可靠度及不間斷，代表在原來會發生交易中斷或是委託狀況不明的情況下，在本系統中可以避免，讓整個交易的過程可以順利完成。在一個分散式的系統架構下，當然還必須考慮其透通性(Transparency)，讓使用者使用起來，就像是在一般的集中式系統上一樣。. 1.4、研究成果. 7.

(19) 本論文所提出的對稱式多主機的分散式系統架構，可以根據各應用領域的特性加以調整，即可完成高穩定度的系統需求，並不局限於電子交易。再者，搭配低成本的建置費用，可以降低建置的門檻，讓該架構可以獲得更為廣泛的運用，讓一般的中小企業、個人、學校都有能力負擔得起，打破高穩定性的系統一定要高花費的迷思。這當中，有幾項的研究成果，分述如下 1、發揮 Zookeeper 的協調服務功能，建置低耦合(loosely coupled)的系統架構，但卻具有高聚合的系統服務(high cohesion)。. 政治大. 2、提出 Propogation monitor 的程序監控概念. 立. 3、發揮 Zookeeper 的協調服務功能，解決對稱式多主機架構所面臨的四大問題。. ‧ 國. 學. 4、針對系統架構，提出雛型驗證的結果。. ‧. 1.5、論文之限制. Nat. sit. n. al. er. io. 有如下的限制. y. 本篇論文所提出的系統架構，在資料流上牽涉到多個處理程序的輸入和輸出，因此. i n U. v. 1、來自於外部實體的資料流，在尚未進入本系統前就遺失時，本系統無法保證該資料. Ch. engchi. 後續能被正常處理，ex.資料的封包在 internet 上就已經發生遺失，或是與本系統串接的外部程式發生異常，無法將資料封包傳進本系統。. 2、主機或處理程序發生異常時，在主機切換完成前，如果有其他外部實體的資料流輸入，原異常程序必須處理的資料流，會因為後續資料流的進入而被覆蓋。這個限制，可用 Zookeeper Locks 來解決，但這部份不在本論文所實作的範圍內。. 3、在訊息上傳至 Zookeeper 前的任何異常，因為訊息尚未透過 Zookeeper 完成通知，其他承接該異常主機執行後續作業的處理程序，將無法得知異常主機當時所要處理的訊息 8.

(20) 內容為何，造成該訊息無法獲得處理。. 4、Zookeeper ensemble 可靠度提供，所須的機器數量：要讓 Zookeeper ensemble 能夠正常運作，機器的數量有一個計算的公式:2f+1[7]，f 是指可以允許機器異常的數量，f 最小為 1，因此主機的數量最少是 2*1+1=3 台。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 9. i n U. v.

(21) 第二章相關研究與技術背景. 2.1、分散式系統的硬體概念(Hardware concept) 在探討集中式和分散式系統的優缺點中，分散式有一潛在的優點是較高的可信度。對於一些比較重要的應用作業，例如原子爐，或是飛機之控制，採用分散式系統以獲得較高之可信度應是其主要的考量。雖然所有的分散式系統都有一個以上的中央處理器. 政治大. (CPU)，但在架構上卻不盡相同，尤其是在機器間的連接方式。對於這種多 CPU 的電腦. 立. 系統架構的分類方式，最常被引用的是採自 Flynn 在 1972 年，所提出的兩個基本特性：. ‧ 國. 學. 指令流(instruction streams)與資料流(data streams)。根據這兩種特性就可以組合成 4 種類別：. ‧. 1、單一指令流；單一資料流(Single instruction，Single data,簡稱 SISD)、. Nat. sit. y. 2、單一指令流；多重資料流(Single instruction，Multiple data,簡稱 SIMD)、. n. al. er. io. 3、多重指令流；單一資料流(Multiple instruction，Single data,簡稱 MISD). i n U. v. 4、多重指令流；多重資料流(Multiple instruction，Multiple data,簡稱 MIMD)。. Ch. engchi. 所有的分散式系統均屬於 MIMD。我們可以將 MIMD 電腦再區分為兩種，一種是擁有共同記憶體的多重處理器(Multi-processes)和另一種不具共同記憶體的多重電腦 (Multi-computers)。其間，基本的差異在於：在多處理器機只有單一的虛擬位址空間，由所有的 CPU 共享；而多重電腦內，每一台主機都擁有其獨立的記憶體空間。本論文所提出之對稱式的架構，是屬於多重電腦的分散式系統，因為各主機之間擁有相同的軟、硬體，讓每一台機器上都『同時』運作相同的處理程序，做相同的事情，儲存同樣的資料，主機之間沒有任何的主從關係，因此定名為對稱式。. 2.2、分散式系統的通透性(Transparency) 10.

(22) 所謂的透通性就是，任何形式的分散式系統，對使用者來說，都必須隱藏其分散式的特性，不論是在呈現上或功能使用上。使用者使用起來，就像是在一般的集中式系統上一樣。根據 RM-ODP(Reference Model for Open Distributed Processing)所分類的通透性有八種[8]，以下針對這八種的分類及其所呈現在使用端的結果，分述如下： 1、存取的通透性(Access Transparency) 使用者不須知道資料如何存取，隱藏資料存取的機制。 2、共時的通透性(Concurrency Transparency). 政治大. 共時存取的影響被隱藏在使用者之後，使用者或處理程序可以同時操作共有的資. 立. 學. ‧ 國. 料。. 3、位置的通透性(Location Transparency). 使用者不須知道物件存取的機器實際位置，而仍然可以存取到該物件。. ‧. 4、遷移的通透性(Migration Transparency). Nat. n. al. er. io. 5、複寫的通透性(Replication Transparency). sit. y. 使用者不須知道服務的動態移動。. i n U. v. 使用者不須知道資料的複製、備份機制，對使用者而言，就只有一份資料。. Ch. engchi. 6、資源的通透性(Resource Transparency). 使用者不須知道主機的停用以及重啟狀況。 7、失敗的通透性(Failure Transparency) 使用者不須知道主機發生異常以及後續的復原、重啟的狀況。 8、邊界的通透性(Federation Transparency) 使用者不須知道跨行政區域及技術邊界的相互作用為何。本論文所提之對稱式電子交易系統，亦為一分散式系統，因此在系統設計時，必須考量上述的通透特性，並且將達成這些特性，列為論文目標之一。. 11.

(23) 2.3、主機的協調-Zookeeper 的導入在對稱式多主機的系統架構下，勢必要有一個協調各主機之間有關『資料共享』、『訊息同步』、『程序監控』及『主機遴選』的運作。針對這四種不同的問題，每個問題，都可以用個別的技術來獲得解決，但要將這些技術整合在一起，卻是一件繁雜的工作。 Zookeeper 在這部分，提供了一些很好的機制，雖然這些機制並不直接針對上述的問題來解決，但卻可以利用這些機制，以較為方便的實作方式來加以處理。. 立. 政治大. 2.3.1、Zookeeper 的介紹. ‧ 國. 學. Zookeeper，從字面上的定義來看，就是動物園管理員。因為在 Hadoop 的生態系中，. ‧. 有以大象為代表圖示的 Hadoop、以蜜蜂為代表圖示的 Hive 以及以小豬為代表圖示的 Pig，. sit. y. Nat. 而 Zookeeper 就是這個生態系中的管理員。Zookeeper 是一個分散式應用程式的協調服. io. al. er. 務，以簡易的介面來提供同步(synchronization)、設定配置維護(configuration maintenance)、. n. 命名(naming)及群組(groups)的服務。. Ch. engchi. i n U. v. 2.3.2、Zookeeper 的 Data Model Zookeeper 有一個階層式的命名空間，而這個命名空間裡的節點稱之為 znode[9]，見圖 2.1。znode 是一個類似檔案系統的目錄，也就是說目錄裡可以像檔案一樣存放資料, 除了存放節點狀態的資料外，還可以存放使用者自訂的資料，見圖 2.2。圖 2.2 中，三個紅框的說明如下 1、第一個紅框處列出了在根目錄下，有 5 個子目錄，分別為 Election、Shared、master、 zookeeper、Machines。 2、第二個紅框表示在 Shared 目錄下，可以有子目錄 SerialNumber 及 EntrustInfo。 3、第三個紅框表示在 EntrustInfo 目錄下，除了紀錄目錄狀態的資料外，還可以記錄使用者自訂的資料。. 12.

(24) 政治大. 圖 2.1 Zookeeper 的階層式命名空間，本圖取自[9]. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 2.2 Zookeeper 的目錄內容 Znode 在建立時會有不同的模式(mode)[10]，而這些不同的模式會決定將來這個節點怎麼運作。以下說明這些不同模式的差異及適用情況。 a.Persistent znode：這種模式的節點，一旦建立後，必須以明確的指令才能被刪除。適合在即使建立該節點的應用程式已經不存在，但資料或狀態仍要被持續保存。. 13.

(25) b.Ephemeral znode：跟 Persistent znode 剛好相反，這類的節點，不須明確的刪除指令，只要建立該節點的應用程式生命週期結束或是將與 Zookeeper 建立的連線關閉，該模式的節點就會自動被刪除。 c.Sequential znode：當指定要建立的 znode 是屬於 sequential 的模式時，Zookeeper 會產生一個唯一的遞增序號放在使用者自訂的 znode 名稱之後。例如，使用者建立一個名為 /task/task-的節點，但透過 Zookeeper 真正建立出來的名稱則是/task/task-000000001。這種模式讓想要建立唯一的節點名稱變得非常容易。後續會運用 Sequential 及 Ephemeral 的特性來完成主機連選的功能。. 學. ‧ 國. 立. 政治大. 2.3.3、Zookeeper 的 WATCH 機制. ‧. 根據 Zookeeper 對 watch 的定義：只要客戶端對資料設定 watch，一旦這個被設定. sit. y. Nat. watch 的資料或狀態發生改變時，客戶端會立刻收到一次性觸發的事件通知[11]。watch. io. er. 的對象就是 znode，因此根據定義可以得知，舉凡 znode 的新增、刪除、資料異動、子. al. n. 節點的異動都會引發 watch 的事件，只要客戶端將想要監控的 znode 設定適當的 watch，. i n C 一旦該 znode 發生異動，立即會收到異動的通知。 hengchi U. v. 2.3.4、Zookeeper 特性的運用在 1.2.研究動機提到，在對稱式設計的系統架構下，勢必要有一個協調各主機之間有關『資料共享』、『訊息同步』、『程序監控』及『主機遴選』的運作，而 Zookeeper 的 Data Model 及 watch 的特性，正好適用於這些協調工作的進行。以下要說明各問題所需使用到的 Zookeeper 特性為何。 1、資料共享：Persistent znode、version control、節點儲存自訂資料。. 14.

(26) 將主機間會共同運用到的資料，依照類型，各別建立一個 Persistent znode，將共享的資料存放於此節點。在資料修改時，根據 Zookeeper 所提供的 version control 機制運作，以確保在共時的情況下，資料異動的正確性。 2、訊息同步：Persistent znode、data watch、節點儲存自訂資料。建立一個 Persistent znode，將須要在各主機之間傳遞的訊息存放於此節點，並且讓每台主機上須要接收此訊息的處理程序，都設立 data 異動的 watch，一旦資料發生異動，所有設立 data 異動 watch 的處理程序，都會收到 Zookeeper 的通知。. 政治大. 3、程序監控：Persistent sequential znode、 Ephemeral znode、child node watch。. 立. 每一個處理程序，都建立一個 Persistent sequential znode，並且 watch 該節點下的. ‧ 國. 學. 所有子節點的狀態。znode 設計程有序號的原因，在於如果是單一處理程序是可以多重啟動的話，必須要有序號來加以區別相同名稱的處理程序，例如. ‧. TradingGateway-000000001、TradingGateway-000000002。在每個處理程序的節點下，再. Nat. sit. y. 針對每個執行緒(Thread)都建立一個 Ephemeral znode 當成是處理程序的子節點，當執行. n. al. er. io. 緒發生異常時，就關閉處理程序與 Zookeeper 之間的連線，一旦連線被關閉，根據. i n U. v. Ephemeral znode 的特性，該執行緒的節點就會自動被刪除。一開始有提到，處理程序會. Ch. engchi. watch 該節點下所有節點的狀態，因此當代表執行緒的子節點被自動刪除時，處理程序會收到通知。當處理程序收到子節點被刪除的通知時，本身會自動結束處理程序，一旦處理程序自動結束，代表處理程序的節點也會被刪除，而監控主機節點之子節點狀態的處理程序，也會因為該節點被刪除而獲得通知。整個監控機制，是由執行緒到處理程序，再到主機層級的一個由內而外的傳遞(propagation)過程，如圖 2.3 所示. 15.

(27) 立. 政治大. ‧ 國. 學. 圖 2.3 Propagation monitor. ‧. 4、主機遴選(Leader election)[12]：Ephemeral sequential znode、child node watch。. sit. y. Nat. 將各主機上參與主機遴選的處理程序，都建立一個 Ephemeral sequential znode。. io. er. Leader 的挑選原則，以 znode 的 sequential 號碼最小的為 Leader。為了避免每次主機遴. al. 選時，都是所有處理程序收到通知，重新執行一次主機遴選的從眾效應(Herd effect)[12]，. n. v i n C h 比自身節點小 1U號的節點，也就是當某個原本代表因此在設計上，每個節點只 watch engchi. Leader 的節點被刪除，只有比這個節點大 1 號的節點會收到通知，而這個大 1 號的節點，也就成為當然的 Leader。圖 2.4 說明了這個設計改念。. 16.

(28) 立. 政治大. ‧ 國. 學. 圖 2.4 Leader election，本圖取自[13]. ‧. 2.3.5、基於 Zookeeper 服務下的對稱式系統架構. sit. y. Nat. io. al. er. 運用 Zookeeper 所提供的服務，整個對稱式系統的概觀如下圖 2.5 所示。每台主機. n. 均有其各自獨立的處理程序，資料庫。訊息可以透過 Zookeeper 共享及同步，並且透過. Ch. engchi. Zookeeper 達到程序監控及主機遴選的功能。. 17. i n U. v.

(29) 圖 2.5 基於 Zookeeper 服務下的對稱式系統. 2.4、免費的資料庫軟體-MariaDB[14] MariaDB 是由 MySQL 的創始人 Michael Widenius 主導開發。2008 年昇陽(SUN)以 10 億美元買下了 MySQL 後，隔年，甲骨文(Oracle)以 74 億美元買下了昇陽，因此，MySQL 的所有權就變成甲骨文所擁有。在甲骨文收購了 MySQL 後，有封閉源始碼的風(MySQL 新的企業延伸套件已採取封閉源始碼)，因此開源社群採用分支的方式來避開這個風險，. 治政而這個分支出來的資料庫管理系統，就是 MariaDB。因為大 MariaDB 在本系統中僅用於立資料的儲存，不須太多進階的應用，因此不做過多功能性的說明。 ‧. ‧ 國. 學. 2.5、資料庫管理視窗化軟體-HeidiSQL[15]. y. Nat. io. sit. MariaDB 跟 MySQL 一樣，本身並不提供 GUI 的管理操作介面，不像 Microsoft SQL. n. al. er. Server 有所謂內建的 Microsoft 管理主控台(MMC-Microsoft Management Console)可以針. Ch. i n U. v. 對 database、table、stored procedure、trigger 等資料庫相關的元件做操作，因此必須要有. engchi. 一套 GUI 的管理介面會比較方便，而 HeidiSQL 就是一套針對 MariaDB 和 MySQL 提供 GUI 管理介面的軟體。圖 2.6 為 HeidiSQL 的操作介面圖。. 18.

(30) 立. 政治大圖 2.6 HeidiSQL 操作介面. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 19. i n U. v.

(31) 第三章系統架構及組件之設計本章節將延續第二章所提出之對稱式多主機的架構、Zookeeper 的特性，MariaDB 的運用，提出系統架構及系統內部所有組成組件之細部設計。這當中包括了 znode、電子資料交換格式、處理程序、資料表、通訊介面、API、及模擬器的設計。細節將分別於後續的章節做詳細的說明。. 3.1、對稱式系統架構之設計. 政治大根據圖 1.3 對稱式多主機系統架構所示，在對稱式的系統中，每台主機均具有相同的處立. ‧ 國. 學. 理程序及儲存的資料。再運用 Zookeeper 所提供的服務，當成是『資料共享』、『訊息傳遞』、『程序監控』及『主機遴選』的平台。完整的基於 Zookeeper 服務的對稱式電子交. ‧. 易系統的宏觀架構圖如 3.1 所示。. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 3.1 基於 Zookeeper 服務的對稱式電子交易系統宏觀架構圖各圖示所代表的意義說明如下 20.

(32) 1、直立長方形虛線：代表對稱式架構下的每一台主機。. 2、橫向長方形虛線：代表 Zookeeper ensemble。. 政治大 3、有陰影效果的長方形：代表外部實體(external entity)。立 ‧. ‧ 國. 學. 4、單箭頭或雙箭頭實線：代表資料流，而線上的文字說明，代表資料流傳遞的方式。. sit. y. Nat. io. n. al. er. 5、無陰影效果的長方形實線:代表處理程序。. Ch. engchi. i n U. 6、柱狀圖:代表資料庫。. 3.2、系統組件之設計. 3.2.1、Zookeeper Znode 的階層結構及建立模式. 21. v.

(33) 根據對於 Zookeeper 的 Data Model 及 watch 機制的研究結果，設計一個能夠解決『資料共享』、『訊息傳遞』、『程序監控』及『主機遴選』的 znode 階層結構，並且要依據所要解決的不同問題，設計不同模式的 znode。圖 3.2 為本系統的 znode 階層結構及 znode 模式。 / /Election(PERSISTENT) Pid.00000001(EPHEMERAL_SEQUENTIAL) Pid.00000002(EPHEMERAL_SEQUENTIAL). 政治大. Pid.0000000n(EPHEMERAL_SEQUENTIAL) /Shared(PERSISTENT). 立. SerialNumber(PERSISTENT). ‧ 國. 學. EntrustInfo(PERSISTENT) /Machines(PERSISTENT) Machine 1(PERSISTENT). ‧. Process 1(PERSISTENT_SEQUENTIAL). Nat. Thread 2(EPHEMERAL). n. al. Thread n(EPHEMERAL). er. io. sit. y. Thread 1(EPHEMERAL). i n U. v. Process n(PERSISTENT_SEQUENTIAL). Ch. engchi. Thread 1(EPHEMERAL). Thread 2(EPHEMERAL). Thread n(EPHEMERAL) Machine n(PERSISTENT). 圖 3.2 znode 階層架構及其建立模式. 接下來，將針對該階層結構、節點的設計用途及模式選定的原因說明如下 1、/：代表根節點 a、用途：Zookeeper 會自動建立一個根節點，所有後續所建立的節點，均屬於這個根節點的子節點。類似 UNIX(Linux)的檔案階層表示方式。 22.

(34) b、模式選定原因：無，因為 Zookeeper 自動產生，因此無法指定建立的模式。 2、/Election：代表參與主機遴選之處理程序的父節點 a、用途：要參與主機遴選的處理程序會掛載(mount)在該節點，成為該節點下的子節點。 b、模式選定原因：該節點不會因為參與主機遴選的處理程序不存在而被刪除，換句話說，即使沒有任何一台主機的處理程序要參與主機遴選，該節點仍然必須要以空節點的形態存在。因此該節點的模式要設計成 PERSISTENT。. 政治大. 3、/Election/Pid.00000001~Pid.0000000n：代表參與主機遴選的處理程序。. 立. a、用途：用來代表要參與主機遴選的處理程序。節點的命名規則為 ProcessID.序號。. ‧ 國. 學. b、模式選定原因：主機遴選的規則是節點名稱中，序號最小的節點即為 Leader。而且代表主機的處理程序，不論任何原因，只要跟 Zookeeper 的連線中斷（當然，. ‧. 包括處理程序的生命週期中止），即代表該主機出現異常情況，已經無發提供原有. Nat. sit. y. 的服務，該節點就必須自動消失，讓監控該節點的其他節點接手該異常節點所需完. n. al. er. io. 成的後續處理。在節點須要有序號及自動消失的設計需求下，必須設計成 EMPHEMERAL_SEQUENTIAL。. Ch. engchi. i n U. v. 4、/Shared：代表資料共享以及訊息傳遞節點的父節點。 a、用途：將屬於據有共享性質的節點歸類在此節點之下。 b、模式選定原因：在系統設計的階段，不論是否已分類出具共享性質的節點為其子節點，該節點都必須存在,所以必須設計為 PERSISTENT。 5、/Shared/SerialNumber：代表共享全域唯一序號的節點。 a、用途：在對稱式的電子交易系統，所有的主機都必須共享同一個流水序號，此節點就是存放此一全域流水序號的節點。 b、模式選定原因：此一節點不屬於任何一台主機所有，諱言之，該節點不會因為主機否存在與否而決定是否存在，所以必須設計為 PERSISTENT。 23.

(35) 6、/Shared/Entrusted：代表訊息同步傳遞的節點。 a、用途：在對稱式的電子交易系統，委託資料因為同時間只有一台主機會收到，其他主機必須透過這個節點來同步接收委託資料。 b、模式選定原因：此一節點不屬於任何一台主機所有，換言之，該節點不會因為主機存在與否而決定是否存在，所以必須設計為 PERSISTENT。以下第 7 點至第 10 點，都跟程序監控有關。在說明下列 4 點之前，必須先瞭解處理程序是如何被監控，如果發生異常，其他處理程序是如何收到通知。在 2.3.4 節，曾. 政治大. 提到監控機制是由內而外的概念，稱之為 Propagation monitor。接下來，就對 Propagation. 立. monitor 做說明。. ‧ 國. 學. 處理程序是否正常跟是否存在，是兩件不一樣的事情。當然，處理程序應該存在時，卻不存在，一定是處理程序發生異常；但反過來說，處理程序存在，就代表處理程序是. ‧. 正常的？那倒未必。這當中就牽涉到何謂處理程序的異常。作業系統在分配資源時，最. Nat. sit. y. 小的單位並非程序(process)，而是執行緒(thread)，也就是監控處理程序的粒度(granularity). n. al. er. io. 要細到執行緒才行。在一個多執行緒的處理程序中，只要有任何一個執行緒發生異常，就該被視為處理程序異常。. Ch. engchi. i n U. v. 處理程序是依附在主機上運作，而主機又是整個系統主機群中的一台，在這個階層的概念下，主機群/主機/處理程序/執行緒的關係，一但執行緒發生異常，這個異常的通知，就必須從執行緒，由內往外一直傳遞(propagate)到主機群。而監控主機群的處理程序，就可以透過監控主機群子節點的異動，得知有某台機器的某個處理程序發生異常。這就像是程式語言中的 Exception handing，將例外訊息一層一層由內往外拋送。所以本篇論文將此監控機制定名為 Propagation monitor。在說明了 Propagation monitor 的運作原理後，接下來將繼續針對程序監控的部分，做節點階層結構、節點的設計用途及模式選定的說明 7、/Machines：代表主機群的父節點。圖 3.3 表示主機群有 3 台主機，主機各為 ubuntu、 24.

(36) ubuntu_2、ubuntu_3。 a、用途：為各主機是否存在提供監控機制。每台主機在處理程序啟動時，將主機名稱掛載至此節點下成為其子節點，然後監控此節點的子節點異動，只要有其他主機從該節點被移除，監控該節點的處理程序就會收到通知。 b、模式選定原因：此一節點為一父節點，不屬於任何一台主機所有，換言之，該節點不會因為主機否存在與否而決定是否存在，所以必須設計為 PERSISTENT。. 立. 政治大. ‧. ‧ 國. 學圖 3.3 主機群與主機的關係圖. y. Nat. io. sit. 8、/Machines /Machine 1~Machine n：代表主機群中的每一台機器，見圖 3.3。. n. al. er. a、用途：以主機名稱為其節點名稱。為各處理程序是否存在提供監控機制。每個. Ch. i n U. v. 處理程序啟動時，就將該程序掛載至此節點下成為其子節點。只要有任何程序從該. engchi. 節點被移除，監控該節點的處理程序就會收到通知。 b、模式選定原因：此一節點，對處理程序而言，是一父節點，不屬於任何一個處理程序所有。換言之，要在代表主機發生異常時的處理程序結束前，明確刪除，所以必須設計為 PERSISTENT。 9、/Machines/Machine 1~Machine n/Process 1~ Process n：代表主機內之處理程序。圖 3.4 代表主機 ubuntu_3 有 3 個處理程序，處理程序的名稱分別為 EntrustProcess-000. 00001、. DBManipulator-00000001、TradingGateway00000001。 a、用途：因為處理程序要依附在主機內運作，所以每一個節點都代表是主機內的. 25.

(37) 一個處理程序。命名規則為程序名稱-序號。須要序號的原因在於，如果單一處理程序是可以多重啟動的話，就必須要有序號來加以區別相同名稱的處理程序，例如 EntrustProcess 被啟動兩次，就會產生 EntrustProcess-00000001 及 Entrust00000002 兩個節點。 b、模式選定原因：此一節點，對執行序而言，是一父節點，不屬於任何一個執行序所有。換言之，該節點的不能因為某個執行緒的異常而自動消失，因為該節點之下還有其他執行緒是正常處理。再者，因為有序號的需求，因此必須被設計. 政治大. 為 PERSISTENT_SEQUENTIAL。. 立. ‧. ‧ 國. 學 y. Nat. er. io. sit. 圖 3.4 程序與主機的關係圖. al. v i n C h DBManipulator-000000014 處理程序下的執行緒。圖 3.5 代表這個處理程序，有兩個執 engchi U n. 10、/Machines /Machine 1~Machine n/Process 1~ Process n/Thread 1~Thread n：代表每個. 行緒，執行緒代號分別是 19 及 20。 a、用途：這是監控機制中最小的單位。必須將每個執行緒在執行的時候，都掛載在所屬的處理程序下，節點名稱是執行緒代號。經由監控處理程序下之執行緒節點的異動，即可得知處理程序是否發生異常。 b、模式選定原因：執行緒已是監控機制中的最小單位，因此當執行緒發生異常時，就必須自動從處理程序的節點中刪除，所以該節點必須設計成 EMPHEMERAL。. 26.

(38) 圖 3.5 程序與執行緒的關係圖. 3.2.2、資料交換格式. 政治大須要兩個元素：資料交換的格式及資料交換的方式。本節僅針對格式的部分說明，而方立. 處理程序之間要能溝通，不論是系統內部程序之間的溝通還是對外的溝通，不外乎. ‧ 國. 學. 式的部分，則留待 3.2.6 說明。. 一般在設計電子資料交換的訊息格式時，都會將格式拆成三個部分，分別是 header、. y. 表 3.1 電子資料交換訊息格式. Nat. io. n. al. sit. body. 根據上述的格式規範，本系統定義的格式如下 1、header. Ch. engchi. tail. er. header. ‧. body 及 tail，因此完整的訊息格式規範，如下表所示. i n U. v. 表 3.2 電子資料交換訊息格式-header 序號. 欄位中文. 資料型態. 起始位置. 說明. 1. 資料長度. 9(4). 0. little endian. 長度說明：因為代表長度的值為 int 的資料型態，而資料是以 byte array 的型態在傳遞，因此要將 int 做位元轉換(bit convert)，讓代表 int 的值，存進 byte array。這當中會牽涉到設計電腦時，有兩中不同的架構來處理記憶體存放區，根據位元組存放在記憶體的順序，可區分為 big endian 及 little endian[16]。本系統採 little endian。以數值 484 為例，經過轉換後，在 byte array 中所存放的值為 27.

(39) 0xE4. 0x01. 0x00. 0x00. 2、tail 表 3.3 電子資料交換訊息格式-tail 序號. 欄位中文. 資料型態. 起始位置. 說明. 1. 結束符號. x(1). 0. 0x0a. 3、body：要依委託的部份及回報的部份，分別設計. 政治大. a、委託電文. 資料型態. 起始位置. 功能代碼. X(1). 0. 2. 分公司. X(4). 1. 含公司碼. 3. 帳號. X(7). 5. 含檢查碼. 4. 新刪改. X(1). 12. 新:I 刪:D 改:C. 5. 商品代碼. X(6). 13. 6. 價格. 9(4,2). 19. 7. 價格別. 8. 委託數量. 9. 盤別. 10. 委託種類. X(1). 33. 0:普通 1:融資 2:融券. 11. 市場別. X(1). 34. T:上市 O:上櫃. 12. 網路單號. X(8). 35. 13. 委託書號. X(20). 43. 14. 來源別. X(2). 63. 15. 買賣別. X(1). 65. B:買 S:賣. 16. 前端序號. X(8). 66. 前端應用程式所帶的序號,可有可無,端看應用程式所需. 17. 下單日期. X(8). 74. yyyyMMdd. 18. 下單時間. X(6). 82. HHmmss. n. e n g c 26 hi 32. 28. y. sit. io. X(1). 25. 1. ‧. Nat. aX(1) l 9(6) C h. 說明. *100,不足左補 0. er. 1. ‧ 國. 欄位中文. 學. 序號. 立表 3.4 電子資料交換訊息格式(委託)-body. i n U. v. 不足左補 0.

(40) 19. 下單 ip. X(15). 88. b、檢核回覆/後台下單/回報電文表 3.5 電子資料交換訊息格式(檢核回覆/後台下單/回報)-body 序號. 欄位中文. 資料型態. 起始位置. 說明. 1. 功能代碼. X(1). 0. 0x08:檢核回覆 0x03: 委回 0x05:成回. 2. 交易日期. X(8). 1. 3. 分公司. X(4). 9. 4. 帳號. X(7). 5. 商品代碼. 6. 價格. X(6) 立. 7. 含公司碼. 政治13 大 20. 含檢查碼. *100,不足左補 0. 價格別. X(1). 32. 8. 操作量. 9(6). 33. 不足左補 0. 9. 網路單號. X(8). 39. 不足左補 0. 10. 流水序號. X(8). 47. 不足左補 0. 11. 前端序號. X(8). 55. 前端應用程式所帶的序號,可有可無,端看應. 來源別. 14. 新刪改. 15. aX(20) l X(2)C h. n. 13. y. sit. io 委託書號. 用程式所需. er. Nat. 12. ‧. ‧ 國. 26. 學. 9(4,2). 63. i n U. v. X(1). e n g c h83i. 市場別. X(1). 86. 16. 盤別. X(1). 87. 17. 委託種類. X(1). 88. 0:普通 1:融資 2:融券. 18. 買賣別. X(1). 89. B:買 S:賣. 19. 下單日期. X(8). 90. yyyyMMdd. 20. 下單時間. X(6). 98. HHmmss. 21. 委託收到時 X(6) 間. 104. HHmmss. 22. 回報來源. X(1). 110. 23. 下單 IP. X(15). 111. 24. 主機 IP. X(15). 126. 85. 29. T:上市 O:上櫃.

(41) 25. 錯誤代碼. X(4). 141. 26. 錯誤訊息. X(32). 145. 0000:成功. 3.2.3、交易處理程序電子交易系統有兩大的資料流必須處理，一個稱之為『委託』，而另一個稱為之為『回報』。舉例來說，以國內股票交易為例，『在整股時段，以 123 塊，購買 XX 電子 10 張』，這是一個委託的要求，這個委託的資料流進入交易系統後，交易系統會經由一連. 政治大. 串的處理程序，將該資料流拆解後重新組合，最後送到交易所，而交易所會根據委託及. 立. 市場的買賣內容，回覆給使用者委託後的結果，就是所謂的回報。因此，接下來將根據. ‧ 國. 學. 委託及回報的流程，來說明電子交易系統各處理程序是如何『串接』完成一筆交易。. ‧. 1、委託. Nat. n. al. er. io. sit. y. 圖 3.6 是委託的流程圖，紅色長方形虛框處所標示的部分，為本論文所討論的系統範圍。. Ch. engchi. i n U. v. 圖 3.6 電子交易委託流程圖. 30.

(42) 以『在整股時段，以 123 塊，購買 XX 電子 10 張』為模擬的情境，說明委託的步驟如下。 step 1、external entity 透過交易 GUI 將委託輸入，並將委託內容組成一份 XML。 step 2、交易 GUI 將 XML 透過通訊中介平台，也就是圖 3.6 中的 Message Oriented Middleware(MOM)，傳送至本系統的入口處理程序，TradingGateway。 step 3、TradingGateway 將收到的 XML 反序列化(Deserialize)為系統內部操作的物件，再將該物件根據下個處理程序所需的內容，序列化(Serialize)為 3.2.2 節所提及的委託電文，. 政治大. 並將該電文送至下個處理程序,EntrustProcessor。. 立. step 4、EntrustProcessor 收到來自 TradingGateway 的委託電文後，將該電文根據規格拆. ‧ 國. 學. 解，之後進行商業邏輯的檢核，產生全域的交易流水序號。. step 5、將檢核的結果、全域流水序號和其他資訊，例如主機 ip，加上原來的委託內容，. ‧. 重新組合成 3.3.2 節所提的檢核回覆/後台下單/回報電文。如果商業邏輯檢核成功，會將. Nat. n. al. er. io. 電文送往至下述的 a、b、d 三個處理程序。. sit. y. 該電文送往至下述的 a、b、c、d 四個處理程序；但如果商業邏輯檢核失敗，只會將該. i n U. v. a、TradingGateway：透過 TradingGateway→MOM→交易 GUI 介面的流程，讓使用者知. Ch. engchi. 道該筆委託已經進入交易系統，也完成商業邏輯之檢核，如果在檢核過程中發生檢核錯誤，例如：價格超過漲跌幅，使用者也可以透過這個流程得知。 b、DBManipulator：將該筆委的商業邏輯檢核紀錄下來，供使用者後續的查詢使用。 c、BOSConnector：該處理程序主要是負責跟交易所的主機連線，將收到的電文送至交易所。實務上，在 BOSConnector 和交易所之間，還會存在一套稱為帳務系統的程式負責對交易所的主機連線，BOSConnector 會將電文送至帳務系統，再由帳務系統將電文送至交易所。但在本論文所討論的範圍中，帳務系統並不扮演任何角色，因此予以省略。 d、Zookeeper service：用意在於讓其他主機也能收到該委託之商業邏輯檢核結果，並將該結果紀錄在資料庫中，如此一來，每台主機的資料庫存都保有一致的資料。 31.

(43) 2、回報圖 3.6 是回報的流程圖，紅色長方形虛框處所標示的部分，為本論文所討論的系統範圍。. 立. 政治大. ‧. ‧ 國. 學 y. Nat. al. er. io. sit. 圖 3.7 電子交易回報流程圖. n. 以『在整股時段，以 123 塊，購買 XX 電子 10 張』為模擬的情境，說明委託的步驟如下。. Ch. engchi. i n U. v. step 1、交易所將委託回報的電文送至 BOSConnector。 step 2、BOSConnector 將該電文送至 DBManipulator 及 TradingGateway。 step 3、DBManipulator 收到電文後，依據 3.3.2 節所提的檢核回覆/後台下單/回報電文的格式，將電文拆解，更新資料庫中的委託資料。 step 4、TradingGateway 收到電文後，檢視電文中的下單 IP 欄位，檢核該筆委托是否是由該本機所下，如果是，則將該電文透過 MOM 傳送至使用者的交易 GUI 介面。如果不是，則檢核下單 IP 欄位所記錄的下單主機，是否正常運作，如果正常運作，代表原下單主機會負責回報的處理。如果主機原下單主機已發生異常，無法提供服務，則要再確 32.

(44) 認本機是否是 Leader 的角色。如果是，則須代理原下單主機處理該筆回報，將該電文透過 MOM 傳送至使用者的交易 GUI 介面；如果不是 Leader，則捨棄該筆回報。. 3.2.4、通訊介面交易系統除了主機內的處理程序必須相互溝通之外，還必須跟其他外部的系統串接，因此在設計時必須針對內部及外部的通訊方式分開設計。以下針對 IPC 及 RPC 的部分說明。. 立. 政治大. 1、IPC (Inter-process communication). ‧ 國. 學. IPC 的種類在不同的作業系統下，會有些許支援上的差異。因為本系統是建置在 Linux 上，因此的 IPC 種類計有[17]. sit. y. Nat. b、Pipes. ‧. a、Signal. e、Semaphores. al. n. d、Message queue. er. io. c、FIFOs(named pipes). Ch. engchi. i n U. v. f、Shared memory 電子交易系統在訊息傳遞方式的設計上，有幾項的考量因素 1、速度要快：電子交易系統，除了穩定度的要求之外，就是速度的要求。實務上，每秒要能處理 100 筆以上的委託，每筆委託的封包大小，會在 2048 bytes 左右。 2、先進先出：電子交易的資料流，基本上都有先後關係的存在，以下單委託為例，一定是先有買賣，才會有取消或是數量的修改，不可能還沒買賣，就去取消或修改一個不存在的交易。雖然在檢核機制上會有防呆的功能，但在交易正確性要高及系統處理複雜度要低的需求下，資料流的順序就成為考量的因素之一了。 33.

(45) 3、實作簡單：對稱式多主機架構主要面臨的問題是在『資料共享』、『訊息同步』、『程序監控』及『主機遴選』，因此會將設計的重點放在如何解決上述的四個問題，至於內部程序的通序機制，實作上越簡單越好。 4、訊息保留追蹤：訊息在傳遞的過程中，在盡量減少 I/O 處理的條件下，要能保留原訊息，以便在遇到異常狀況時可以檢視及追蹤原訊息內容。 5、處理程序不需有相依或是主從關係才能傳遞訊息：系統內的處理程序，各自獨立，沒有階層上的相依關係或是主從關係，但卻要能相互傳遞訊息。. 政治大. 基於上述的考量因素，在速度的部分，差異不大，因此剩下的因素就成為選擇的依據。. 立. 而 named piped 因為具有下列特徵[18]而成為最後決定的方式. ‧ 國. 學. a、named pipe 實際上是一個存在於硬碟的特殊種類檔案(稱為 FIFO file)，不同於一般的檔案，FIFO file 不包含任何使用者資訊。在實作 named pipe 就像操作檔案一般，並不困. ‧. 難。. Nat. sit. y. b、named pipe 的運作是基於先進先出的原則。. n. al. er. io. c、named piped 可以在處理程序結束所有的 I/O 分享時，仍然留在檔案系統供後續使用。. i n U. v. d、不同階層關係下的程序，也能透過 named piped 傳遞訊息。這一點是相對於 Pipes 來比較。. Ch. engchi. 2、RPC(Remote process communication) RPC 的部分，已經超出本論文所界定的系統範圍，但因為在概念性驗證(Proof of Concept)的階段，必須要能提供模擬的情境，因此仍有 RPC 之實作上的必要。電子交易系統運用 RPC，在實務上，大部分都是異質作業系統的溝通，因此只要跟 OS 有高度相依性的作法，就不予以考量，類似 Microsoft MessageQueue。實務上，已有非常多成熟的產品可以運用，最常被業界所使用的計有，IBM 的 WebSphere MQ，TIBCO，MTALK。當然，這些都必須花費較高的建置及維運成本，在節省成本的考量下，最普遍的做法就是 TCP Socket，而且這個作法還是市場上普遍存在的作法。因此在普遍性的考量之下， 34.

(46) 本系統採用 TCP Socket 當成是 RPC 實作的方式。. 3.2.5、Zookeeper Wrapper-API 為了讓應用程式在撰寫的時候,不須考慮 Zookeeper 的運作原理及如何將處理程序及執行緒一層一層掛載在適當的節點，因此，本論文將這些繁雜的實作封裝起來，僅提供 API(ZKLib.jar)，如圖 3.8 紅框處所示。. 立. 政治大. ‧. ‧ 國. 學. io. sit. y. Nat. 圖 3.8Zookeeper Wrapper-ZKLib. n. al. er. 應用程式只須根據情況的需要，呼叫相對應的 API，處理所需要的事件，達到資料. Ch. i n U. v. 共享，訊息傳遞程序監控及主機遴選。以下就針對這些 API 做說明。. engchi. 1、class ZKThread：執行緒父類別。要被監控的執行緒必須繼承該父類別。 2、ZKController(String connectionString,int sessionTimeout)：建構子參數說明 a、connectionString：Zookeeper 的連線字串,形式為 ip:port,多主機之間以逗號相隔，例如 192.168.112.131:2181,192.168.112.134:2181,192.168.112.135:2181 b、sessionTimeout:與 Zookeeper 連線逾時的時間。 3、boolean ZKController.mountMachine() ：將機器掛載至 znode 4、boolean ZKController.unmountMachine() ：將機器從 znode 卸載. 35.

(47) 5、boolean ZKController.mountProcess(String processName)：程序的掛載參數說明 processName：要掛載的處理程序名稱 6、boolean ZKController.unmountProcess()：程序的卸載 7、void ZKController.uploadData(String path,String data) 參數說明 a、path：資料要上傳至 Zookeeper 的路徑。. 政治大. b、data:要上傳至 Zookeeper 的資料。. 立. 8、String ZKController.genSeqNum()：產生全域唯一的序號. ‧ 國. 學. 9、public List<String> ZKController.getipOfMachines()：取得主機群中所有正常服務之主機 ip。. ‧. 10、public byte[] ZKController.getEntrustInfo()：取得檢核回覆的資料。. Nat. sit. y. 11、void ZKController.addDatauploadListener(DatauploadListener listener) ：增加資. al. n. 參數說明. er. io. 料上傳的事件監聽器。. Ch. listener: 資料上傳的事件監聽器. engchi. i n U. v. 12、void ZKController.addThreadExpiredListener(ThreadExpiredListener listener) ：增加執行緒異常的事件監聽器參數說明 listener: 執行緒異常的事件監聽器 13、void ZKController.addProcessRemoveListener(ProcessRemoveListener listener) ：增加處理程序被移除的事件監聽器參數說明 listener: 處理程序被移除的事件監聽器 36.

(48) 14、NodeMonitor.Start(String connectionString):啟動 Leader election 參數說明 connectionString：Zookeeper 的連線字串,形式為 ip:port,多主機之間以逗號相隔，例如 192.168.112.131:2181,192.168.112.134:2181,192.168.112.135:2181 15、NodeMonitor.Stop()：結束 Leader election 16、NodeMonitor. addLeaderChangeListener(LeaderChangeListener listener): 增加 Leader 異動的事件監聽器. 政治大. 參數說明. 立. listener: Leader 異動的事件監聽器. ‧. ‧ 國. 學. 3.2.6、模擬器. 根據圖 3.6 及圖 3.7 所示，本論文所探討的系統範圍外，尚有三個外部實體，雖然. Nat. sit. y. 這部分不在系統範圍內，而且會根據實務上的需求而有所異動，但為了概念性驗證(Proof. al. n. 說明。. er. io. of Concept)，因此必須要有這部份的模擬器設計及實作。以下將針對這些模擬器的用途. Ch. engchi. i n U. v. 1、Order Emulator：下單及回報模擬器，見圖 3.9 所示。代表的是圖 3.6 及圖 3.7 左上角所標示之 external entity。可以透過此 GUI 進行下單的交易並且呈現下單後的委託及成交回報。. 37.

(49) 立. 政治大. ‧ 國. 學 ‧. 圖 3.9 下單及回報模擬器. Nat. sit. y. 2、MOM Emulator：MOM 模擬器，見圖 3.10 所示。代表的是圖 3.6 及圖 3.7 所標示之. n. al. er. io. Message Oriented Middleware。是下單及回報模擬器和交易系統之間的通訊橋梁。與 Order. i n U. Emulator 和交易系統的通訊方式，均採 TCP Socket。. Ch. engchi. v. 圖 3.10 MOM(Message Oriented Middleware)模擬器 38.

(50) Exchange Emulator：交易所模擬器，見圖 3.11 所示。代表的是圖 3.6 及圖 3.7 右下角所標示之 external entity。可以模擬交易所接收來自交易系統的委託，以及將委託回報/成交回報回覆給交易系統。與交易系統的通訊方式，均採 TCP Socket。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 3.11 交易所模擬器. 39.

(51) 第四章概念性驗證(Proof of Concept) 本論文所提出之對稱式的多主機架構，運用在電子交易系統上，會面臨四大問題，分別是『資料共享』、『訊息同步』、『程序監控』及『主機遴選』，當然在系統建置成本的部分，以免授權費用的資料庫管理系統為優先考量。在本論文的第一章，說明了這四大問題的源起，第二章，延續第一章的四大問題，提出了 Zookeeper 的 Data Model 及 watch 機制如何能解決這四大問題，並且針對免費的. 政治大. 資料庫管理系統-MariaDB 做了介紹，第三章則針對第二章所探討的解決方案提出系統. 立. 架構及元件的設計。. ‧ 國. 學. 本章節就要針對前三章節所提出之概念及設計，模擬 4 種情境，在 3 台虛擬主機上驗證其可行性。. ‧ sit. y. Nat. 4.1、驗證環境. al. n. 硬體規格：. er. io. 驗證環境之軟、硬體規格如下. Ch. engchi. i n U. 1、CPU：Intel Core i5 3230M 2.6GHz 虛擬主機共享 2、RAM：2GB 3、硬碟：50GB 4、數量：3 台軟體規格： 1、作業系統：Ubuntu 12.04 2、JAVA 版本:1.6.0_45 3、Microsoft .NET framework 版本:4.0 4、Zookeeper 版本:3.4.5 40. v.

(52) 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 節有探討，資料共享在電子交易系統的應用方面，是要產生一個全域的流水序號，因此不論委託下單至哪一台主機，流水序號應該都是要續編。. Nat. al. 圖 4.1MOM Emulator 交易主機選擇區. er. io. sit. y. ‧. 模擬方式：MOM Emulator 有主機選擇區，見圖 4.1. n. v i n Ch 在下單委託之前，可以選擇要下單至哪一台交易主機，交易主機選定後執行下單交易。 engchi U 預計結果：Exchange Enumlator 有一個交易序號的欄位，預計在切換交易主機後的每筆委託之交易序號均能續編。模擬結果：在分別從 192.168.112.131、192.168.112.134、192.168.112.135 執行下單委託後，可以從 Exchange Enumlator 的交易序號欄位看到交易序號分別是 00000511、00000512、00000513，見如圖 4.2 所示，模擬結果符合預期。. 41.

(53) 立. 政治大. ‧ 國. 學. 圖 4.2 交易序號續編. ‧. 4.2.2、訊息同步. sit. y. Nat. io. 資料。. er. 說明：訊息同步代表不論從任何一台主機委託下單，每一台主機都必須要有相同的委託. al. n. v i n Ch 模擬方式：MOM Emulator 有主機選擇區，見圖 i U e n g c h 4.1。在下單委託之前，可以選擇要下單至哪一台交易主機，交易主機選定後執行下單交易，每台主機委託 3 筆委託，3 台主機共 9 筆委託。預計結果：Order Emulator 的『查詢區』，可以針對各主機資料庫進行委託之查詢，如圖 4.2 所示。預計在任何一台主機上，都可以查出分別在 3 台不同主機所下之委託資料。驗證委託資料的欄位為交易序號單號。. 圖 4.3 Order Emulator 查詢區. 42.

(54) 模擬結果：分別從 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 查詢區. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4.5 主機 192.168.112.134 查詢區. 43.

(55) 圖 4.6 主機 192.168.112.135 查詢區. 4.2.3、程序監控說明：當某一台主機的處理程序發生異常，其他主機必須被通知有該狀況的發生，並且要有主機負責該異常主機後續之委託處理。模擬方式：Order Emulator 有傳送異常訊息的功能，見圖 4.7。. 政治大. 立圖 4.7 Order Emulator 傳送異常訊息之檢核框. ‧ 國. 學. 該檢核框打勾後的委託，在主機端收到後，會產生一個處理程序異常的狀況。委託經選. ‧. 定下單至主機 192.168.112.131，如圖 4.7。. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4.8 選定 192.168.112.131 為交易主機但因 192.168.112.131 發生處理程序異常，192.168.112.134(跟後續即將討論的 Leader election 有關)接手後續之委託處理。預計結果：. 44.

(56) 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。. ‧ 國. 學. 模擬結果均符合預期結果。. ‧. n. er. io. sit. y. Nat. al. v. 圖 4.9 Order Emulator 傳送異常訊息. Ch. engchi. i n U. 圖 4.10 委託單之下單主機資訊. 4.2.4、主機遴選說明：要求-回覆(request-response)模式的通訊方式，並不適用於有推播(push)機制的電子交易系統。原因在於這類的電子交易系統，要求和回覆是可以分屬於不同的通道(channel)，因此，即便是系統內沒有任何一台主機收到使用者發出的要求訊息，但仍然都會收到來自於其他通道發出要求後的外部回覆。 45.

(57) 模擬方式：在 Exchange Emulator 有一『外部單模擬區』，見圖 4.11。. 圖 4.11 外部單模擬區這就是在模擬另一個下單的通道。將股票代碼、價格、張數、買賣別輸入完畢後，按下『回報送出』，及代表另一個通道已完成委託下單。預計結果：. 政治大 2、有主機遴選機制：Order Emulator 可以呈現非由 Order Emulator 所交易的委託。立. 1、沒有主機遴選機制：Order Emulator 不會呈現不是由 Order Emulator 所交易的委託。. ‧ 國. 學. 模擬結果：. 1、主機在沒有啟動主機遴選的情況下(見圖 4.12)，Exchange Emulator 交易兩筆委託，. ‧. 交易序號分別為 EE163601 和 EE163831，均未在 Order Emulator 中呈現，見圖 4.14。. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4.12 主機遴選未啟動 2、主機在啟動主機遴選的情況下(見圖 4.13) ，Exchange Emulator 交易一筆委託，交易序號為 EE164054，已能在 Order Emulator 中呈現，見圖 4.14 紅框處。模擬結果均符合預期結果。. 46.