0

构建一个.net web 应用程序，所以我只想知道

  • 如果数据库崩溃，Web 应用程序会发生什么？
  • 如何在用户不知道发生了什么的情况下维护网站？
  • 如何处理用户输入的数据？
  • 说如果我使用状态管理，我可以通过什么方式保存数据？
4

2 回答 2

1

这完全取决于您付出了多少努力；例如，您可以启用数据库故障转移，这往往很昂贵（第二台服务器、许可证等），但可以非常快速地恢复到这对服务器。您可以编写您的应用程序以在内存中执行某些操作（如果您的应用程序被回收，这将变得很棘手），或者到一个独立的商店。

这里最常见的选择是务实的：我们需要一个数据库（无论是 sql、nosql 还是其他；一些中央数据存储库）；如果数据库服务器离线，应用程序也会离线。您应该希望在您的数据库层上有很好的正常运行时间；您最好将时间花在尝试了解如何提高正常运行时间上。

只读应用程序的另一个选择是在每个应用层服务器上保留数据库副本，并逐步更新。当应用程序服务器启动时，（通常）是本地数据库。

于 2011-04-06T09:37:06.457 回答
0

正如 Marc 所说，这是一件大事，老实说，我不会依赖 Stack Overflow 上陌生人的知识来形成意见。从广义上讲，如今硬件等都非常可靠，而且花费相对较少的钱，您就可以实现非常高的可用性（RAID 驱动器、NAS 存储等）。如果您需要比通过此途径实现的更高水平的可用性，那么您就进入了专业领域 - 您需要以前做过的人的建议。它也很昂贵——从 99.9% 的正常运行时间到 99.99% 的运行时间很容易使解决方案的成本翻倍。三心二意的措施往往会使事情变得更糟，而不是更好，因为这会在基础设施和代码中增加额外的复杂性。复杂性是错误所在，错误比硬件故障更有效地降低了可用性。

话说回来....

这完全取决于您的应用程序的数据密集程度、应用程序的可缓存程度、数据的复杂程度等。

您可以查看集群数据库——在许可/硬件和 DBA 时间方面都很昂贵，但理论上您可以跨多个数据中心进行集群，获得接近 100% 的正常运行时间。

您可以查看消息传递解决方案，而不是直接访问数据库；消息队列解决方案（微软有一个）是一种与标准“ASP.Net 应用程序直接与数据库对话”完全不同的应用程序架构方式，但可以处理大量数据，并提供非常高的故障转移保证。

您可以查看缓存层 - 将所有数据放在缓存中可能会让您保持工作站点的错觉，即使底层数据库已关闭。

于 2011-04-06T10:03:18.010 回答