1 需求

檔案上傳功能在IM系統裡，一般都會涉及到的。那檔案上傳也分單聊和群聊兩種情況。之前系統實現了單聊傳送檔案的情況，目前需要實現群聊裡傳送檔案。群聊和單聊傳送檔案功能，對客戶端來說流程可能差不多，單對伺服器來說，差別就不是一點點了。

 

2 實現

2.1 現有系統實現

現有系統中，檔案上傳功能的實現如下：

1 客戶端通過與訊息伺服器的長連線，傳送檔案請求到訊息伺服器，請求資訊包括髮送使用者id、接收使用者id、檔名稱、檔案大小、傳送模式（離線，線上，現在實現的是離線模式）。

2 訊息伺服器接收到客戶端的請求後，傳送訊息到檔案伺服器。

3 檔案伺服器根據請求，生成任務id。

4 檔案伺服器應答訊息伺服器請求，應答資訊主要包括任務id、傳送使用者id等。

5 訊息伺服器應答客戶端請求，應答資訊主要包括任務id、檔案伺服器ip資訊等。這裡的檔案伺服器ip資訊是訊息伺服器通過請求檔案伺服器獲得。這個ip資訊是在檔案伺服器的配置檔案裡配置的。

6 客戶端拿到檔案伺服器ip資訊，就連線檔案伺服器，拿著任務id資訊傳送登入請求到檔案伺服器。

7 客戶端登入成功後，檔案伺服器向客戶端拉取檔案資料，並儲存成檔案。

8 檔案伺服器拉取完檔案資料後，傳送檔案狀態為完成狀態到客戶端。

9 客戶端收到傳送完成狀態，傳送增加離線檔案請求到訊息伺服器。

10 訊息伺服器收到請求，傳送請求到DB伺服器，儲存離線檔案資訊到資料庫，資訊包括髮送使用者id，接收使用者id，檔名稱，檔案大小，任務id，檔案伺服器ip資訊等。當接收使用者線上時候，傳送檔案通知訊息到接收使用者。

 

 

在客戶端收到檔案通知訊息或者拉取到有離線檔案列表時候，就需要進行檔案下載。現有系統，檔案下載功能的實現如下：

1 客戶端登入檔案伺服器，這裡不用通過訊息伺服器獲取檔案伺服器的地址，而是在離線檔案資訊裡包括了。

2 客戶端登入成功後，傳送拉取檔案資料請求。

3 當客戶端拉取檔案資料完成，檔案伺服器傳送檔案狀態為完成狀態到客戶端。

4 客戶端傳送刪除離線檔案請求到訊息伺服器，訊息伺服器請求DB伺服器更改檔案狀態。

2.2 問題

1 流程相對複雜。

2 任務id是根據檔案關聯，一次只能傳送一個檔案請求。

3 根據現有的檔案上傳和下載邏輯，當有多臺檔案伺服器的時候，通過哪個上傳的，還必須通過哪個下載。

4 檔案上傳完成後，客戶端傳送訊息到訊息伺服器，再通過DB伺服器儲存檔案資訊到資料庫。那如果客戶端不傳送，那麼檔案其實已經是上傳成功了的。

5 傳送增加或刪除離線檔案請求都是單向的，伺服器沒有給客戶端做應答。這個不能保證資料一致性。

6 上傳完成和下載完成的狀態通知是沒有必要的。伺服器判斷完成的標誌是資料傳輸的大小是否為0，那這個在應答的時候傳輸為0的請求，那麼客戶端即知道檔案傳輸完成了。

7 丟包判斷，目前沒有對丟包判斷。即傳輸資料大小和包裡的資料大小是否一致的判斷。

 

2.3 改進方案

1 上傳檔案的時候，檔案伺服器地址，改為在登入伺服器裡配置獲取。同時在有多臺檔案伺服器時候，進行均衡處理。

2 任務id改為由客戶端生成。

3 下載檔案的時候，檔案伺服器地址也用登入時候返回的檔案伺服器地址。如果考慮負載情況，那在客戶端登入檔案伺服器的時候，返回登入失敗。如果客戶端登入檔案伺服器失敗，則再請求一次登入伺服器，獲取新的檔案伺服器地址。或者由檔案伺服器獲取新的地址，在登入返回的時候一起返回到客戶端。

4 上傳完成和下載完成狀態不單獨傳送，用請求或應答包裡的大小為0作為判斷依據。

5 增加和刪除離線檔案請求，改為伺服器內部處理訊息。