多服務器數據共享是目前許多企業開始使用的一種方法。它可以在多個服務器之間獲取相應的信息，減輕服務器的壓力，方便開發人員的操作。對于如何實現多服務器數據間的信息共享，有很多方法可以實現。至于哪種方法更安全有效，我們還需要繼續探索。

在創建用于上載和操作文件的多步驟表單時，如果應用程序在負載平衡器后面的多個服務器上運行，則我們需要確保文件在整個過程中都可用，因此無論哪個服務器數據在每個步驟處理該過程。

當為處理用戶上傳的文件提供某些函數時，該文件必須可用于整個執行過程。簡單的上傳和保存操作不會導致任何問題。但是，如果除此之外，文件必須在保存之前運行，并且應用程序在負載平衡器后面的多個服務器上運行，則我們需要確保該文件對每次運行該進程的任何服務器數據都可用。

例如，多步驟“上載用戶的化身”功能可能要求用戶在步驟1中上載化身，在步驟2中裁剪它，并在步驟3中保存它。在步驟中將文件上載到服務器后，該文件必須可用于處理步驟2和步驟3中的請求的任何服務器數據，并且步驟2和步驟1中的請求可以相同或不同。

一種不太可靠的方法是將步驟1中上載的文件復制到所有其他服務器數據，以便所有文件都可用。然而，這種方法不僅極其復雜，而且不可行：例如，如果一個站點在多個區域的數百臺服務器上運行，則無法實現。

一種可能的解決方案是在負載平衡器上啟用粘性會話，它總是將同一服務器分配給給定的會話。然后，步驟1、2和3將由同一服務器處理，步驟1中上載到服務器的文件仍將在步驟2和3中使用，但粘性會話并不完全可靠：如果服務器在步驟2之間崩潰，則負載平衡器必須分配不同的服務器數據，破壞功能和用戶體驗。類似地，在特殊情況下，總是將同一個服務器分配給一個會話可能會減慢來自負擔過重的服務器的響應時間。

一個更合適的解決方案是讓所有服務器數據都可以訪問存儲庫中的文件副本。然后，在步驟1中將文件上載到服務器后，服務器將其上載到存儲庫（或者，您可以直接從客戶端上載文件到存儲庫，繞過服務器）；服務器處理步驟2將從存儲庫下載文件，對其進行操作，然后將其上載到存儲庫；最后，服務器處理步驟3將從存儲庫下載并保存。

事實上，一些外國人通過AWS S3在多個服務器數據之間共享數據，并在S3上執行最基本的操作：上傳、下載和列出文件，每個文件幾乎不需要幾行代碼。該解決方案的簡單性表明，將云服務集成到應用程序中并不困難，并且可以由不熟悉云的開發人員完成。