多服务器数据共享是目前许多企业开始使用的一种方法。它可以在多个服务器之间获取相应的信息，减轻服务器的压力，方便开发人员的操作。对于如何实现多服务器数据间的信息共享，有很多方法可以实现。至于哪种方法更安全有效，我们还需要继续探索。
在创建用于上载和操作文件的多步骤表单时，如果应用程序在负载平衡器后面的多个服务器上运行，则我们需要确保文件在整个过程中都可用，因此无论哪个服务器数据在每个步骤处理该过程。
当为处理用户上传的文件提供某些函数时，该文件必须可用于整个执行过程。简单的上传和保存操作不会导致任何问题。但是，如果除此之外，文件必须在保存之前运行，并且应用程序在负载平衡器后面的多个服务器上运行，则我们需要确保该文件对每次运行该进程的任何服务器数据都可用。
例如，多步骤“上载用户的化身”功能可能要求用户在步骤1中上载化身，在步骤2中裁剪它，并在步骤3中保存它。在步骤中将文件上载到服务器后，该文件必须可用于处理步骤2和步骤3中的请求的任何服务器数据，并且步骤2和步骤1中的请求可以相同或不同。
一种不太可靠的方法是将步骤1中上载的文件复制到所有其他服务器数据，以便所有文件都可用。然而，这种方法不仅极其复杂，而且不可行：例如，如果一个站点在多个区域的数百台服务器上运行，则无法实现。
一种可能的解决方案是在负载平衡器上启用粘性会话，它总是将同一服务器分配给给定的会话。然后，步骤1、2和3将由同一服务器处理，步骤1中上载到服务器的文件仍将在步骤2和3中使用，但粘性会话并不完全可靠：如果服务器在步骤2之间崩溃，则负载平衡器必须分配不同的服务器数据，破坏功能和用户体验。类似地，在特殊情况下，总是将同一个服务器分配给一个会话可能会减慢来自负担过重的服务器的响应时间。
一个更合适的解决方案是让所有服务器数据都可以访问存储库中的文件副本。然后，在步骤1中将文件上载到服务器后，服务器将其上载到存储库（或者，您可以直接从客户端上载文件到存储库，绕过服务器）；服务器处理步骤2将从存储库下载文件，对其进行操作，然后将其上载到存储库；最后，服务器处理步骤3将从存储库下载并保存。
事实上，一些外国人通过AWS S3在多个服务器数据之间共享数据，并在S3上执行最基本的操作：上传、下载和列出文件，每个文件几乎不需要几行代码。该解决方案的简单性表明，将云服务集成到应用程序中并不困难，并且可以由不熟悉云的开发人员完成。
