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 電腦再區分為兩種，一種是
‧
上一樣。根據 RM-ODP(Reference Model for Open Distributed Processing)所分類的通透性 有八種[8]，以下針對這八種的分類及其所呈現在使用端的結果，分述如下：1、存取的通透性(Access Transparency)
使用者不須知道資料如何存取，隱藏資料存取的機制。
2、共時的通透性(Concurrency Transparency)
共時存取的影響被隱藏在使用者之後，使用者或處理程序可以同時操作共有的資 料。
3、位置的通透性(Location Transparency)
使用者不須知道物件存取的機器實際位置，而仍然可以存取到該物件。
4、遷移的通透性(Migration Transparency) 使用者不須知道服務的動態移動。
5、複寫的通透性(Replication Transparency)
使用者不須知道資料的複製、備份機制，對使用者而言，就只有一份資料。
6、資源的通透性(Resource Transparency) 使用者不須知道主機的停用以及重啟狀況。
7、失敗的通透性(Failure Transparency)
使用者不須知道主機發生異常以及後續的復原、重啟的狀況。
8、邊界的通透性(Federation Transparency)
使用者不須知道跨行政區域及技術邊界的相互作用為何。
本論文所提之對稱式電子交易系統，亦為一分散式系統，因此在系統設計時，
必須考量上述的通透特性，並且將達成這些特性，列為論文目標之一。
‧
2.3、主機的協調-Zookeeper 的導入
在對稱式多主機的系統架構下，勢必要有一個協調各主機之間有關 『資料共享』、
『訊息同步』、『程序監控』及『主機遴選』的運作。針對這四種不同的問題，每個問題，
都可以用個別的技術來獲得解決，但要將這些技術整合在一起，卻是一件繁雜的工作。
Zookeeper 在這部分，提供了一些很好的機制，雖然這些機制並不直接針對上述的問題 來解決，但卻可以利用這些機制，以較為方便的實作方式來加以處理。
2.3.1、Zookeeper 的介紹
Zookeeper，從字面上的定義來看，就是動物園管理員。因為在 Hadoop 的生態系中，
有以大象為代表圖示的 Hadoop、以蜜蜂為代表圖示的 Hive 以及以小豬為代表圖示的 Pig，
而 Zookeeper 就是這個生態系中的管理員。Zookeeper 是一個分散式應用程式的協調服 務，以簡易的介面來提供同步(synchronization)、設定配置維護 (configuration maintenance)、 命名(naming)及群組(groups)的服務。
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 目錄下，除了紀錄目錄狀態的資料外，還可以記錄使 用者自訂的資料。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 2.1 Zookeeper 的階層式命名空間，本圖取自[9]
圖 2.2 Zookeeper 的目錄內容
Znode 在建立時會有不同的模式(mode)[10]，而這些不同的模式會決定將來這個節 點怎麼運作。以下說明這些不同模式的差異及適用情況。
a.Persistent znode：這種模式的節點，一旦建立後，必須以明確的指令才能被刪除。適 合在即使建立該節點的應用程式已經不存在，但資料或狀態仍要被持續保存。
‧
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，一旦 這個被設定 watch 的資料或狀態發生改變時，客戶端會立刻收到一次性觸發的事件通知[11]。watch 的對象就是 znode，因此根據定義可以得知，舉凡 znode 的新增、刪除、資料異動、子 節點的異動都會引發 watch 的事件，只要客戶端將想要監控的 znode 設定適當的 watch，
一旦該 znode 發生異動，立即會收到異動的通知。
2.3.4、Zookeeper 特性的運用
在 1.2.研究動機提到，在對稱式設計的系統架構下，勢必要有一個協調各主機之間 有關『資料共享』、『訊息同步』、『程序監控』及『主機遴選』的運作，而 Zookeeper 的 Data Model 及 watch 的特性，正好適用於這些協調工作的進行。以下要說明各問題所需 使用到的 Zookeeper 特性為何。
1、資料共享：Persistent znode、version control、節點儲存自訂資料。
‧
的資料存放於此節點。在資料修改時，根據 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。在每個處理程序的節點下，再 針對每個執行緒(Thread)都建立一個 Ephemeral znode 當成是處理程序的子節點，當執行 緒發生異常時，就關閉處理程序與 Zookeeper 之間的連線，一旦連線被關閉，根據 Ephemeral znode 的特性，該執行緒的節點就會自動被刪除。一開始有提到，處理程序會 watch 該節點下所有節點的狀態，因此當代表執行緒的子節點被自動刪除時，處理程序 會收到通知。當處理程序收到子節點被刪除的通知時，本身會自動結束處理程序，一旦 處理程序自動結束，代表處理程序的節點也會被刪除，而監控主機節點之子節點狀態的 處理程序，也會因為該節點被刪除而獲得通知。整個監控機制，是由執行緒到處理程序，
再到主機層級的一個由內而外的傳遞(propagation)過程，如圖 2.3 所示
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 2.3 Propagation monitor
4、主機遴選(Leader election)[12]：Ephemeral sequential znode、child node watch。
將各主機上參與主機遴選的處理程序，都建立一個 Ephemeral sequential znode。
Leader 的挑選原則，以 znode 的 sequential 號碼最小的為 Leader。為了避免每次主機遴 選時，都是所有處理程序收到通知，重新執行一次主機遴選的從眾效應(Herd effect)[12]，
因此在設計上，每個節點只 watch 比自身節點小 1 號的節點，也就是當某個原本代表 Leader 的節點被刪除，只有比這個節點大 1 號的節點會收到通知，而這個大 1 號的節點，
也就成為當然的 Leader。圖 2.4 說明了這個設計改念。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 2.4 Leader election，本圖取自[13]
2.3.5、基於 Zookeeper 服務下的對稱式系統架構
運用 Zookeeper 所提供的服務，整個對稱式系統的概觀如下圖 2.5 所示。每台主機 均有其各自獨立的處理程序，資料庫。訊息可以透過 Zookeeper 共享及同步，並且透過 Zookeeper 達到程序監控及主機遴選的功能。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 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]
MariaDB 跟 MySQL 一樣，本身並不提供 GUI 的管理操作介面，不像 Microsoft SQL Server 有所謂內建的 Microsoft 管理主控台(MMC-Microsoft Management Console)可以針 對 database、table、stored procedure、trigger 等資料庫相關的元件做操作，因此必須要有 一套 GUI 的管理介面會比較方便，而 HeidiSQL 就是一套針對 MariaDB 和 MySQL 提供 GUI 管理介面的軟體。圖 2.6 為 HeidiSQL 的操作介面圖。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 2.6 HeidiSQL 操作介面
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University