這實際上是在Web應用程序中非常常見的。由於我沒有很多具體的工作要做,所以我會給你一些想法和一般性建議。
如果你'自己推出',你不想做的事情就是將你上傳的字節存儲到數據庫中。如果做得好,特別是在人們可能上傳任意大小的文件的情況下,這是非常困難的。之前破解過這個螺母,我會說從最高抽象開始。用戶可以上傳文件並返回包含文件位置的URL。因此,用戶POST一個文件並通過新文件的URL獲取通常爲201/204的響應。即使你使用的插座,我會考慮基於HTTP的方法,使您可以滾動相同的服務出多種類型的客戶端和平臺。不過,你也許可以在套接字中編寫一個非常高效的實現。
無論是套接字還是HTTP請求,服務器端的以下內容都是相同的。在服務器端你有一個接口,比如FileLocator接受一個文件ID和一個用戶。 FileSystemFileLocator實現FileLocator並將文件定位到文件系統上。棘手的部分是不在目錄中放置超過1000個左右的目錄或對象。一種常用技術(如果所分配的每個文件一個唯一的編號),是零墊和反向數量,以便你有12個數字。每個三位數字組成爲一個目錄名稱,最後3位是文件名稱:/123/400/000/000.pdf。爲了取回漂亮的文件名,您可以跟蹤數據庫中的位置,原始文件名和一些元數據。
然後你可以實現S3FileLocator,它使用S3來存儲文件。 MongoFileLocator存儲在蒙戈的數據,等等,你將有挑戰是弄清楚如何確保在數據庫中的元數據(你可以很快訪問)保持同步與現實上的文件系統或S3 。
當讀取文件時,只讀取文件的小塊(如16k),並將其返回給用戶,直到完成。如果您一次讀入文件,則會非常低效地使用內存。例如,在一個項目中,我是通過讀取從SQL Server表的文件到內存中實現這樣的傻子,然後,在內存,複製的對象將它寫回給客戶端。該數據庫包含50兆字節的演示文稿。
有什麼困惑嗎? HTTP vs FTP vs普通套接字並不重要,只需選擇一個即可。 (儘管我建議不要使用FTP,但它使得處理防火牆和網絡隧道變得更加困難) – Joni 2013-03-03 19:08:56
@Joni,謝謝你的評論。我喜歡DropBox的概念。那麼是否有可能通過HTTP實現類似DropBox的功能?或哪個更好? – 2013-03-03 19:13:37