C# 将文件上载到多个服务器

我看到了很多关于上传多个文件的问题，但是没有一个关于上传一个文件到多个服务器的问题，所以这里是

我有一个ASP.NET应用程序，将在两个负载平衡的服务器上运行，我想允许用户上传文件，并让它们在两个服务器上结束。最干净的方法是什么？我正在使用IIS 6 btw

我想到的一些想法是：

1） 使用指向两台服务器都可以访问的共享位置的虚拟目录。如果应用程序在网络服务上运行，是否会出现访问问题？我假设应用程序需要作为共享位置计算机上的用户帐户运行。应如何为此设置权限

2） 如果我可以通过jQuery将请求发布到我的两台服务器上，并通过它们的端口号引用它们，那就太好了。即使服务器在同一个域上，这也违反了同源策略，对吗

---

有没有其他我忽略的解决方案？其他网站是如何做到这一点的？

我想你更仔细地考虑这个问题——有一对（或更多）服务器意味着它们中的一些会在某些时候离线（至少偶尔启动）。 并非所有服务器都在线时的上载将无法立即发送到所有服务器，因此您需要一个中间服务器（除非它本身高度可用，否则这将是一个故障点）或一个排队系统来“记住”哪些文件在哪里，并在相关服务器恢复时传输这些文件

---

此外，您还需要一个备份系统，以及一些将新配置的服务器添加到集群的方法。您还需要一种方法来监视这些文件是否相同，以防它们不同步。您的架构需要仔细考虑。我没有答案：）

我看到这个问题在NAS中得到了解决，使用应用程序池的凭据可以向该NAS读/写文件。确保您的NAS设置为高可用性，以防止单点故障，即：带raid的热插拔、多个阵列控制器、电源等等

---

您还可以在服务器上安装文件夹监控软件，以保持某些目录的同步。我不推荐这种解决方案。

最干净的方法是将文件转发到服务器端。如果您通过JavaScript强制两次上传，那么您不仅需要担心XSS保护措施，还需要强制用户对每个文件使用两次非常有限的上行带宽

无论如何，你不应该向客户透露这种细节。浏览器不需要知道文件在哪里结束，只需要知道将文件发送给谁。如果在服务器端保留该逻辑，不仅可以隐藏细节（从而减少出错和利用漏洞的可能性），还可以更好地控制流程。您可以稍后创建一个网关服务来处理大量后端存储，并且可以更好地处理出现故障的服务器。您可以将失败的上载排队，然后重试。如果您在服务器端执行这些操作，那么所有这些操作的成本都非常低，但是要在客户端可靠地工作，这是一件痛苦的事情

---

将后端逻辑保留在后端。负载平衡应该对用户隐藏，因此无需告诉用户文件的确切发送位置。如果需要，将其设置为可选，但对他们隐藏操作。只需吞下网关服务器上的文件（可以是任何一个负载平衡服务器——事实上，它也应该是负载平衡的，因此它应该与其中任何一个一起工作），然后从那里将其发送到其他服务器。从服务器到服务器的传输可能也会更快。

如果NAS可用，您最好的选择肯定是NAS—一个不专门与任何机器关联的共享文件系统。然后，您可以专注于通过群集前端使NAS高度可用

如果这不是一个选项，您可以在每台机器上使用一个虚拟目录，该目录指向其中一台机器上的一个文件夹，但这样会丢失冗余

我在工作中也面临着同样的挑战。我的应用程序很小，但需要高可用性，但看不到NAS。因此，在每台机器的web.config中，我都会列出上传文件应该存储的所有UNC路径。上传到临时文件夹后，我将文件一个接一个地复制到每台机器上。它不是完美的——一台机器可能会宕机，在这种情况下，当它出现时，它可能没有所有的文件（而且副本会因为寻找丢失的机器而变慢）——但在我的情况下，上传是如此的少，因此不值得改进

---

正如其他人所提到的，Javascript是正确的。上传一次。

您如何设置权限以便应用程序写入每台机器？您的应用程序是作为网络服务运行还是模拟具有访问每台计算机的权限的ID？他们会模拟文件副本。我们有一个域帐户，但如果两台服务器有完全相同的用户名/密码，您也可以互换使用。您可能想要加密配置文件中的密码。您最后做了什么？我正在寻找一个解决方案。我真的不记得发帖时我在做什么项目，所以我不确定我最终会为此做什么。在某种程度上，我最终使用了这样一个事实，即这些多个web服务器碰巧与一个SQL Server实例通信，因此我在数据库中填充了一些文件，即LOLOL。你的想法可能会有所不同，这很可能是个糟糕的主意。哦，是的，这是个糟糕的主意。哈哈……我们存储在项目目录中。计划现在将该网站移动到azure和ha环境中，因此我们的任务是改变文件存储方式。有什么想法吗？