第三章 系統架構與實作
3.4 使用 MQ 調節上傳
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
31
由圖 14 所示，由於不同感測實驗可能具有相同的感測項目或屬性，因此，ELF 必 須載明實驗 ID。同時，也必須具備客戶端 ID 用以辨識。另外， ELF 於感測項目、屬 性等之描述上與 ECF:DSL 同樣參考項目屬性代碼表進行描述。同時也載明了感測時間，
以做為時效性之參考。以上述規格製定 ELF 之後，為了保障感測數據的安全，在上傳的 實際運作上，將經過加密及解密處理。
3.4 使用 MQ 調節上傳
在平台的運作上，有一個情況需要特別注意及考量；由於伺服器有其負載上限，當客戶 端參與者日益眾多，隨著資料上傳 ELF 數目大量增加，很可能造成伺服器一時無法負荷 的狀況。如圖 15 所示。系統若出現問題，將致使執行效率變差，甚至導致當機，造成 ELC 上傳失敗或遺失。
圖 15：伺服器因客戶端上傳 ELF 而負荷過重
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
32
因此，為了因應大量 ELF 的上傳數據處理，本研究採用訊息佇列(Message Queue，
簡稱 MQ)來做為兩端之間傳輸數據的緩衝處理。MQ 是一種訊息傳送服務，具備三項主 要之特點：
1. 非同步通訊協定：由於採取非同步處理，所以當客戶端送出數據後，不需等待 伺服器端之回應。可以使兩邊不會因為相互等待而使得效率降低。
2. 先進先出之處理方式：由於先進先出，先送達之資料，可確保被優先處理，不 會有無限等待之問題發生。
3. 保證訊息送達：沒有被取出的資料將永遠保持於 MQ server 之中，等候被領出，
因此不會時間過久被刪除或遺失之問題。
圖 16：使用 MQ 調節 ELF 上傳
如圖 16 所示，我們於兩端之間設置 RabbitMQ[18]以解決此問題。RabbitMQ 為一套 由 Erlang 程式語言所撰寫之 MQ server，遵循 Mozilla Public License 開源協議。因此，
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
33
客戶端上傳 ELF 時，不直接上傳至伺服器端，而且發送 ELF 訊息至 RabbitMQ 上先暫 存，發送之後，立即處理其它工作，完全不需要等候伺服器端的回應。伺服器端則依負 載能力，逐步從 RabbitMQ 上取回 ELF，將資料存入資料庫中。
3.4.1 資料儲存原則
本研究於資料儲存原則上，本研究採用雙軌制，將平台所產生之資料分為兩類以不同方 式分別因應及處理：
圖 17：DAO 示意圖
1. 感測實驗設定資料：此類資料由於資料量相較較少且較為固定，因此我們採用 傳統關聯式資料庫(Relational Database Management System)以進行儲存。實作上，
我們透過安裝 PostgreSQL[19]以進行此部份的資料存取處理。
2. 感測結果數據：此類資料由於資料量大，加上未來可能持續性的增加，因此我 們採用 NoSQL 來處理。NoSQL 是對於不同於傳統的關係型資料庫的資料庫管 理系統的一種統稱，具備水平可擴展性的特徵，可彈性化的增加儲存空間。實
‧
作上，我們透過安裝 Apache HBase[20]以進行此部份的資料存取處理。
另外，不論採用的方式是上述任何一種，在實作上，任何元件都必須透過資料庫存 取物件(Data Access Object，簡稱 DAO)，才能對資料庫進行存取，以確保資料存取的唯 一管道。
Application Server Glassfish 3.1.2 with JDK 7 [15][16][17]
MQ Server RabbitMQ 3.0.1 Relational Database PostgreSQL 9.2
NoSQL HBase 0.94.7 with JDK 6