的角度來看，Active/Stand by、Active/Passive(Hot standby)、Active/Active，都再再說明，
不論是人為的介入或是系統偵測異常時的自動切換，唯一的目的，就是希望當異常發生
‧
infrastructure 的設計，被應用在電子交易領域，磁碟陣列(RAID, Redundant Array of Independent Disks)， 資料庫鏡像 (Database mirror) ，叢集 (Cluster)架構， Storage area network(SAN)等等。處理器之間以匯流排(Bus)緊密連接，而各處理器之間擁有稱為主記憶體(Main memory) 的 集 中式 共享記憶體 (Centrailzed shared Memory) ，處理器之間具有高度的耦合性 (Tightly-coupled)。請見下圖 1.1
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 1.1 對稱式多處理器系統，本圖取自[3]。
但如果將各處理器，分屬於不同的主機上，彼此之間是透過高速網路裝置來傳遞訊 息，沒有共享的主記憶體，各主機擁有獨立的記憶體及 I/O，處理器之間具有低耦合性 (Loosely-coupled)。這類型的多處理系統，又可稱為多重主機(Multicomputers)系統[4]，
見圖 1.2。
圖 1.2 多重主機系統，本圖取自[5]
在分散式系統的優點評估中，有一潛在的優點，就是穩定度高[4]。要能提供一個高 穩定性的電子交易系統，無疑必須採取分散式的多主機架構，而且，為了考量當主機發
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
生異常時，其他主機接續處理的時間可以最短，因此在設計上，各主機的軟、硬體資源、
處理程序是可以呈現『對稱式(symmetric)』的分配。所謂對稱，即讓每一台機器上都『同 時』運作相同的處理程序，做相同的事情，儲存同樣的資料，正因為機器之間沒有所謂 的主從關係，所以每台機器角色平等，如此一來，即便整個系統的機器群發生異常到只 剩下一台機器可以運作，該單一機器仍能繼續提供原有的服務，但如此的設計架構，在 負載平衡(Load balance)上，並沒有辦法提供效益，因為每一台機器都有著相同的訊息量。
對稱式多主機系統的概觀如圖 1.3 所示
圖 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
‧
但都有缺點。leading code 的缺點在於，一個固定編碼長度(一般來說是 8bytes)的流水序 號，拿至少 1byte 當 leading code 時，整個可編序號的範圍就少了 10 倍，而指定每台機
Joe Armstrong 在其著作『Programming Erlang：Software for a Concurrent World』對 於程序的監控，有如是的說明：『如果有人死掉了，其他人會注意到』[6]。這也就表示，
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
自於其他通道發出要求後的外部回覆。舉例來說，我們的系統為 M，有主機 M 1 至 M n，
其他系統為 T，使用者從系統 T 發出一個要求，該要求經過外部處理後的回覆，除了會 回覆給系統 T 之外，還會回覆給我們的系統 M 1 至 M n。為什麼會出現這種狀況？原因 在於各系統之間要能看到彼此之間的交易內容。問題來了，我們系統的主機有 M 1 至 M n，每一台都收到相同的回覆訊息，如果每一台都往前端推播，則前端會收到 n-1 個重 複的回覆，但不推播也不行，因為不推播，前端就不會收到交易結果的回覆。因此系統 中只能有一台是負責這類沒有 request，但卻有 response 的推播功能。既然只能有一台，
接下來的問題產生了：要哪一台負責？決定的機制為何？如果這台發生異常，哪一台要 接手？而這些問題，正是有關主機遴選的議題。
綜合上述的說明，可以知道，在對稱式多主機設計的系統架構下，勢必要有協調各 主機之間有關『資料共享』、『訊息同步』、『程序監控』及『主機遴選』的運作問題需要 解決。如圖 1.4 所示。圖中標示 1 之處，代表要產生全域的流水序號，這跟資料共享有 關；圖中標示 2 之處，代表訊息在其中一台主機收到後，必須同步到其他主機；圖中標 示 3 之處，代表該如何監控處理程序之異常情況；圖中標示 4 之處，代表當所有主機都 收到外部訊息的時候，該由哪一台主機負責處理，才不會出現重複處理的問題，這會跟 主機遴選有關。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 1.4 對稱式多主機系統面臨的問題-架構圖
除此之外，主機的資料儲存會涉及到資料庫的運用，目前市面上的商用資料庫都所 費不貲，如果要建立一台以上的對稱式多主機系統，一台主機就要有一個資料庫，那所 有主機加起來的資料庫授權費用更會高得讓人望之怯步，因此在資料庫的選定上，必須 朝向低成本，甚至是免費的資料庫管理系統，如此一來，才能符合高穩定且低成本的系 統目標。
1.3、研究目標
以對稱式多主機的架構，設計一套低成本，高可靠度、不間斷服務的電子交易系統 是本篇論文的目標。所謂高可靠度及不間斷，代表在原來會發生交易中斷或是委託狀況 不明的情況下，在本系統中可以避免，讓整個交易的過程可以順利完成。在一個分散式 的系統架構下，當然還必須考慮其透通性(Transparency)，讓使用者使用起來，就像是在 一般的集中式系統上一樣。
1.4、研究成果
‧
1、發揮 Zookeeper 的協調服務功能，建置低耦合(loosely coupled)的系統架構，但卻具有 高聚合的系統服務(high cohesion)。
2、提出 Propogation monitor 的程序監控概念
3、發揮 Zookeeper 的協調服務功能，解決對稱式多主機架構所面臨的四大問題。 後續能被正常處理，ex.資料的封包在 internet 上就已經發生遺失，或是與本系統串接的 外部程式發生異常，無法將資料封包傳進本系統。
2、主機或處理程序發生異常時，在主機切換完成前，如果有其他外部實體的資料流輸 入，原異常程序必須處理的資料流，會因為後續資料流的進入而被覆蓋。這個限制，可 用 Zookeeper Locks 來解決，但這部份不在本論文所實作的範圍內。
3、在訊息上傳至 Zookeeper 前的任何異常，因為訊息尚未透過 Zookeeper 完成通知，其 他承接該異常主機執行後續作業的處理程序，將無法得知異常主機當時所要處理的訊息
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
內容為何，造成該訊息無法獲得處理。
4、Zookeeper ensemble 可靠度提供，所須的機器數量：要讓 Zookeeper ensemble 能夠正 常運作，機器的數量有一個計算的公式:2f+1[7]，f 是指可以允許機器異常的數量，f 最 小為 1，因此主機的數量最少是 2*1+1=3 台。
‧
2.1、分散式系統的硬體概念(Hardware concept)
在探討集中式和分散式系統的優缺點中，分散式有一潛在的優點是較高的可信度。
對於一些比較重要的應用作業，例如原子爐，或是飛機之控制，採用分散式系統以獲得 較高之可信度應是其主要的考量。雖然所有的分散式系統都有一個以上的中央處理器 (CPU)，但在架構上卻不盡相同，尤其是在機器間的連接方式。對於這種多 CPU 的電腦 系統架構的分類方式，最常被引用的是採自 Flynn 在 1972 年，所提出的兩個基本特性：
指令流(instruction streams)與資料流(data streams)。根據這兩種特性就可以組合成 4 種類 別：
1、單一指令流；單一資料流(Single instruction，Single data,簡稱 SISD)、
2、單一指令流；多重資料流(Single instruction，Multiple data,簡稱 SIMD)、
3、多重指令流；單一資料流(Multiple instruction，Single data,簡稱 MISD) 4、多重指令流；多重資料流(Multiple instruction，Multiple data,簡稱 MIMD)。
所有的分散式系統均屬於 MIMD。我們可以將 MIMD 電腦再區分為兩種，一種是