构建。net web应用程序，所以我只想知道
- 如果数据库崩溃，web应用程序会发生什么? 如何在用户不知道发生了什么的情况下维护网站?
- 如何处理用户输入的数据?
- 说，如果我使用状态管理，我可以用什么方式保存数据?
这完全取决于你付出了多少努力;例如，您可以启用数据库故障转移，这往往是昂贵的(第二台服务器、许可证等)，但可以非常快速地恢复到对上。你可以让你的应用做一些的事情，要么在内存中(如果你的应用循环使用，这就很棘手了)，要么在一个独立的商店中。
最常见的 选择在这里是实用的:我们需要一个数据库(无论是sql, nosql，或其他;一些中央数据存储库);如果数据库服务器脱机，应用程序也会脱机。你应该在你的数据库层上寻找很好的正常运行时间;你最好把时间花在看看如何提高的正常运行时间上。
只读应用程序的另一个选择是在每个应用程序层服务器上保留DB的副本，并增量更新。当应用服务器启动时，本地数据库(通常)也会启动。正如Marc所说，这是一件大事，老实说，我不会依赖Stack Overflow上陌生人的知识来形成意见。一般来说，现在的硬件等都是相当可靠的，而且花费相对较少的钱，就可以获得非常高的可用性(RAID驱动器、NAS存储等)。如果你需要更高的可用性水平，而不是通过这种方式实现，那么你就进入了专家领域——你需要以前做过这件事的人的建议。它也很昂贵——从99.9%上升到99.99%很容易使解决方案的成本翻倍。三心二意的度量往往会使事情变得更糟，而不是更好，因为它在基础设施和代码中都增加了额外的复杂性。复杂性是bug存在的地方，bug比硬件故障更有效地降低可用性。
话虽如此....
这完全取决于你的应用程序的数据密集程度，应用程序的可缓存程度，数据的复杂程度等。
您可以查看一个集群数据库——在许可/硬件和DBA时间方面都很昂贵，但理论上您可以跨多个数据中心进行集群，从而获得接近100%的启动时间。
您可以查看消息传递解决方案，而不是直接访问数据库;消息队列解决方案(Microsoft有一个)是一种从根本上不同于标准的"ASP"架构应用程序的方法。. Net应用程序直接与数据库对话"，但可以处理大量数据，并提供非常高的故障转移保证。
你可以看看缓存层——把你所有的数据放在缓存中可能会让你保持一个工作站点的假象，即使底层数据库已经关闭。