文件上傳到EC2，首先要EBS卷，然後移動到S3

Question

http://farm8.staticflickr.com/7020/6702134377_cf70482470_z.jpg

了可怕的畫好抱歉，但它似乎是一個更好的方式來組織我的想法和傳達出來。我一直在努力研究如何創建一個最佳的去耦合輕鬆擴展系統，以便將文件上傳到AWS上的Web應用程序。

直接上傳到S3將工作，除了文件需要立即訪問上傳者的操作，然後一旦操縱，他們可以到S3，他們將被提供給所有實例。

我的想法是創建一個類似glusterfs的SAN，然後直接上傳到服務器上。我還沒有排除它，但從不同的來源，這種解決方案的可靠性可能不太理想（如果有人有更好的見解，我很樂意聽到）。無論如何，我想制定一個更「開箱即用」（在AWS的情況下）的解決方案。

所以爲了詳細說明這個圖表，我希望文件能夠上傳到它碰巧去的實例的本地文件系統，這是一個EBS卷。該文件的存儲位置將不會提供給公衆（即的/ tmp /上傳/），它仍然可以通過例如，通過在PHP中的ReadFile（）操作訪問，使用戶可以看到並上傳後立即對其進行操作。一旦用戶完成操作文件，一條消息將其移至s3可以在SQS中排隊。

我的問題是再一次我保存實例上的文件「本地」（這可能是任何情況下，由於負載均衡），我怎麼可以記錄它是（在DB）的實例，以便後續請求通過PHP讀取或移動文件會發現所述文件。

如果有人在此更多的經驗，有一定的見解，我將非常感激。謝謝。

Answer 1

我有一個不同的設計，可能會解決你的問題的建議。

爲什麼不是總是先將文件寫入S3？然後將它複製到本地EBS文件系統中，無論你在哪個節點上工作（我不太清楚你需要做什麼操作，但我希望這沒關係）。完成修改文件後，只需將其寫回S3並從本地EBS卷中刪除即可。

通過這種方式，羣集中的任何節點都不需要知道其他哪些節點可能擁有該文件，因爲答案總是在S3中。並且通過本地刪除文件，如果其他節點更新文件，則會獲得新版本的文件。

如果每次從S3複製文件過於昂貴（太大或者您不喜歡延遲），您可能會考慮另一件事。你可以打開的負載平衡器會議親和力（AWS稱之爲粘性會話）。這可以由您自己的cookie或ELB處理。現在來自同一瀏覽器的後續請求來到同一個羣集節點。只需根據S3副本檢查本地EBS捲上文件的修改時間，如果更新，請進行更換。然後，您可以在文件正在處理時利用本地EBS文件系統。

當然也有一堆東西我不明白你的系統。爲此道歉。