第三章、 研究方法： 系統設計與架構
6、 檔案與資料夾同步
在混合雲環境之下，為了確保使用者在多個不同裝置上，檔案的一致性，其 包含檔案資料的一致性和檔案清單的一致性，本研究針對使用者本地端、公有雲 和私有雲三方的檔案，設計一個完整的檔案同步機制，詳細方法如下所述。
6.1 檔案系統監控模組
使用者在本地端，例如：桌上型電腦、筆記型電腦，需要安裝客戶端應用程 式，客戶端應用程式會包含檔案系統監控模組，該模組主要用於監控使用者於監 控資料夾內進行的檔案和資料夾異動事件，整理如表五。
表 五：檔案系統監控事件 檔案監控事件
新建檔案 修改檔案 更名檔案 刪除檔案 移動檔案
資料夾監控事件
新增資料夾 刪除資料夾 移動資料夾
其中，移動檔案事件，系統會依判斷為新建檔案和刪除檔案兩種事件。而由 於資料夾內可能是多層結構，有包含子資料夾和檔案，所以刪除資料夾事件，系 統會依序判斷維刪除資料夾內檔案和刪除子資料夾，直到最後一層完畢；移動資 料夾事件，系統會依序判斷為新增資料夾、新增資料夾內檔案和子資料夾，直到 最後一層完畢，最後會再觸發刪除資料夾事件。
檔案監控模組監聽到事件觸發後，會依據 producer-consumer pattern，檔案監 控模組作為 producer，其會把每次產生的異動事件儲存進 Queue 資料結構，而同 步模組作為 consumer，會不斷從該 Queue 資料結構把事件抓出來，再進行同步 工 作 。 其 中 ， 檔 案 和 資 料 夾 異 動 事 件 會 轉 為 物 件 並 以𝑂𝑂𝑂𝑂𝑂𝑂𝑉𝑉𝑂𝑂𝑂𝑂𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑜𝑜𝑠𝑠𝑜𝑜=
�𝑂𝑂𝐼𝐼𝐼𝐼, 𝑂𝑂𝐶𝐶ℎ𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜, 𝑂𝑂𝑃𝑃𝑎𝑎𝑃𝑃ℎ, 𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑃𝑃𝑎𝑎𝑃𝑃ℎ, 𝑂𝑂𝐿𝐿𝑎𝑎𝑠𝑠𝑃𝑃𝐿𝐿𝑜𝑜𝑂𝑂𝐿𝐿𝐿𝐿𝐿𝐿𝑜𝑜𝑂𝑂𝑎𝑎𝐿𝐿𝑜𝑜𝑜𝑜, 𝑂𝑂𝑆𝑆𝐿𝐿𝑆𝑆𝑜𝑜, 𝑂𝑂𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜�存進 Queue。
6.2 同步機制設計
同步機制的設計分為，客戶端和網站 Portal 對同步伺服器之間的同步訊息溝 通以及檔案和資料夾的同步，如下所述。
( 1 ). 同步訊息溝通
同步模組從 Queue 把使用者異動事件取出來，接著判斷操作行為和類型是 檔案或資料夾以及其相關資料後，不會馬上就開始進行檔案同步工作，而是會先 和同步伺服器進行檔案同步要求，得到同步許可後，才會開始進行檔案或資料夾 同步，完成後會再告知同步伺服器，同步訊息的溝通是透過通訊伺服器上的 RabbitMQ 來進行處理，此三次訊息溝通的詳細順序圖如圖三十四。
圖 三十四：三次同步訊息溝通順序圖
此 三 次 同 步 訊 息 ： 請 求 同 步 ， 其 資 料 內 容 為 𝑂𝑂𝑂𝑂𝑂𝑂𝑉𝑉𝑂𝑂𝑂𝑂𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑜𝑜𝑠𝑠𝑠𝑠𝑜𝑜𝑠𝑠𝑃𝑃=
�𝑂𝑂𝑈𝑈𝐼𝐼𝐼𝐼, 𝑂𝑂𝐼𝐼𝑃𝑃𝑜𝑜𝑜𝑜𝐼𝐼𝐼𝐼, 𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝐼𝐼𝑃𝑃𝑜𝑜𝑜𝑜𝐼𝐼𝐼𝐼, 𝑂𝑂𝑃𝑃𝑎𝑎𝑃𝑃ℎ, 𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑃𝑃𝑎𝑎𝑃𝑃ℎ, 𝑂𝑂𝐶𝐶𝑂𝑂𝐿𝐿𝑜𝑜𝑠𝑠𝑃𝑃𝐶𝐶𝑜𝑜𝑠𝑠, 𝑂𝑂𝐶𝐶ℎ𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜, 𝑂𝑂𝑎𝑎𝑜𝑜𝑤𝑤𝑜𝑜𝑠𝑠, 𝑂𝑂𝐸𝐸𝑜𝑜𝑎𝑎𝐿𝐿𝑂𝑂, 𝑂𝑂𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜, 𝑂𝑂𝐻𝐻𝑎𝑎𝑠𝑠ℎ�、回應同步請求，其 內 容為𝑂𝑂𝑂𝑂𝑂𝑂𝑉𝑉𝑂𝑂𝑂𝑂𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑜𝑜𝑠𝑠𝑎𝑎𝑜𝑜𝑠𝑠𝑠𝑠𝑜𝑜= �𝑂𝑂𝐼𝐼𝑃𝑃𝑜𝑜𝑜𝑜𝐼𝐼𝐼𝐼, 𝐼𝐼𝐶𝐶ℎ𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜, 𝑂𝑂𝐼𝐼𝑃𝑃𝑜𝑜𝑜𝑜𝑠𝑠𝑜𝑜𝑂𝑂𝑜𝑜, 𝑂𝑂𝑃𝑃𝑎𝑎𝑃𝑃ℎ, 𝑂𝑂𝑆𝑆𝑃𝑃𝑎𝑎𝑃𝑃𝑠𝑠𝑠𝑠, 𝑂𝑂𝐴𝐴𝑠𝑠𝑃𝑃ℎ�和 同步完 成， 其內 容為
𝑂𝑂𝑂𝑂𝑂𝑂𝑉𝑉𝑂𝑂𝑂𝑂 = �𝑂𝑂 , 𝑂𝑂 , 𝑂𝑂 , 𝑂𝑂 , 𝑂𝑂 , 𝑂𝑂 , 𝑂𝑂 , 𝑂𝑂 , 𝑂𝑂 , 𝑂𝑂 , 𝑂𝑂 �，
皆會轉成 JSON 資料格式並以字串型態，來進行訊息傳遞和交換。
( 2 ). 檔案與資料夾兩階段同步
當第二次同步訊息溝通結束，同步伺服器允許客戶端開始進行同步，客戶端 應用程式、網站 Portal 會把檔案或資料夾，以 OpenStack Swift 所提供的 REST API 同步到儲存伺服器，此為第一階段同步。同步完成後，客戶端應用程式、網站 Portal 會向同步伺服器送出第三次同步完成訊息，當同步伺服器收到同步完成訊 息，此時就會再把該檔案或資料夾，以 REST API 從 OpenStack Swift 取得，再透 過要同步的雲端儲存服務所提供的 API，把檔案和資料夾同步到對應的資料夾，
此為第二階段同步。從客戶端和網站 Portal 到同步伺服器，而同步伺服器再同步 到公、私有雲端儲存服務，此兩階段的同步順序如圖三十五。
圖 三十五：兩階段同步順序圖
本系統檔案和資料夾同步，透過先同步到 OpenStack Swift 之上，在轉而同 步到公有雲和其他私有雲上，這樣的做法可以確保使用者每一份同步到雲端的檔 案和資料夾，在私有雲內部都將會有一份備份。
6.3 雲端檔案與資料夾異動偵測
使用者進行檔案和資料夾異動操作，除了在本系統的客戶端和網站 Portal 上操作之外，也有可能是直接在已連結的雲端儲存服務，利用其所提供的介面，
進行檔案異動操作。本系統為了達到雲端和本地端以及不同裝置之間的檔案一致 性，會採用主動通知(Push)和被動掃描(Polling)混合的方式，以下將針對此兩種 操作情境和機制詳細說明。
( 1 ). 本系統上操作
使用者在本系統客戶端和網站 Portal 上，進行檔案異動操作，當同步伺服器 開始進行第二階段的同步時，如果該使用者還有其他裝置，也安裝了客戶端應用 程式並且是啟動狀態，為了維持不同裝置上的檔案一致性，同步伺服器會採用主 動通知(Push)該使用者其他客戶端應用程式，使其來進行檔案同步，詳細流程如 圖三十六。
圖 三十六：客戶端應用程式更新本地端順序圖
該通知同步訊息內容為，𝑂𝑂𝑂𝑂𝑂𝑂𝑉𝑉𝑂𝑂𝑂𝑂𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑜𝑜𝑃𝑃𝐿𝐿𝐿𝐿𝐿𝐿𝑠𝑠𝑎𝑎𝑃𝑃𝐿𝐿𝑜𝑜𝑠𝑠= �𝑂𝑂𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜, 𝐼𝐼𝐶𝐶ℎ𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜𝑎𝑎𝑠𝑠𝑎𝑎𝑜𝑜, 𝑂𝑂𝑠𝑠𝑜𝑜𝑤𝑤𝑠𝑠𝑜𝑜𝑤𝑤𝑃𝑃𝑎𝑎𝑃𝑃ℎ, 𝑂𝑂𝑠𝑠𝑜𝑜𝑤𝑤𝑠𝑠𝑜𝑜𝑤𝑤𝑠𝑠𝑜𝑜𝑤𝑤𝑃𝑃𝑎𝑎𝑃𝑃ℎ�，也 會轉成 JSON 資料格式並以字串型態，來進行訊息傳遞。
( 2 ). 雲端儲存服務上操作
使用者直接在已和本系統連結的雲端儲存服務，例如：Google、Dropbox、
Microsoft 以及 Amazon，上面系統對應的資料夾進行檔案異動，客戶端應用程式 會採用定期抓取(Polling)雲端服務上的檔案清單，和本地端檔案清單進行比對，
有異動則會直接對本地端檔案進行異動，比對沒有變化則不進行動作，詳細如圖 三十七。
圖 三十七：客戶端應用程式檢查雲端儲存順序圖
當檔案從雲端同步到本地端完成後，客戶端應用程式會偵測到檔案系統異動 事件，則會依照兩階段同步流程，進行後續同步工作。
6.4 檔案清單一致性
為了要確保使用者在各裝置上的檔案清單的一致性，本系統在伺服器端 MongoDB 資料庫會儲存使用者的完整檔案清單，除此之外，在客戶端應用程式 和伺服器端還會有維護清單一致性的處理機制，詳細的設計如下所述。
( 1 ). 客戶端應用程式
客戶端應用程式在啟動和恢復網路連線狀態時，皆會和同步伺服器要求登入 使用者的完整檔案清單，並檢查在監控資料夾內的檔案清單是否符合。如果有不 相同或不存在檔案、資料夾，則依據其建立時間，檢查是否大於檔案清單的最後 修改時間，來判斷要新建或移除。
( 2 ). 同步伺服器
同步伺服器在每次第一階段同步完成，都會把此次同步的檔案或資料夾的完 整路徑，來更新 MongoDB 的使用者檔案清單，儲存的 JSON 結構如圖三十八。
圖 三十八：MongoDB 檔案清單 Files Collection 的 JSON 結構
儲存的每一筆資料都是以使用者為單位，並且以其 UID 作為唯一識別，當 使用者進行檔案同步，系統會解析檔案的完整路徑，分為根資料夾和其餘路徑來 作為儲存的依據。其中，根資料夾，例如：Google Drive、Microsoft OneDrive、
Dropbox、Amazon S3 各自會作為儲存 JSON 資料 list 陣列裡面的一筆資料，代 表該雲端儲存服務的最上層目錄，而 sub 陣列則存有根資料夾之下每一個資料夾 路徑，並記錄其內所有檔案的資訊，此外會根據該目錄隸屬於的雲端儲存服務，
額外儲存相關屬性。
6.5 檔案與資料夾同步 API
系統對內除了使用 OpenStack Swift 所提供的 REST API 之外，對外還會額外 提供檔案同步的 API，功能包含檔案和資料夾的新增、刪除、修改以及查詢，提 供網站 Portal 程式和擁有存取權限的用戶使用，此 API 介面的同步功能如表六。
表 六：檔案與資料夾同步 API 介面
類型 API 參數 功能描述
檔案 POST (token,path,content) 建立或更新檔案資料 PUT (token,path,newPath) 更名檔案
GET (token,path) 取得檔案資料 DELETE (token,path) 刪除檔案資料 資料夾 POST (token,path) 建立資料夾
PUT (token,path,newPath) 更名資料夾 GET (token,path) 下載整個資料夾 DELETE (token,path) 刪除整個資料夾
其他 LIST (token,path) 取得檔案和資料夾清單 資料夾下載 API，會提存取的資料夾內所有檔案打包成壓縮檔(.zip)，供介接 的程式或使用者取得；資料夾刪除 API，則是會把刪除的資料夾內，包含檔案以 及子資料夾，直到最後一層全部進行刪除。