如果数据库崩溃，Web 应用程序会发生什么情况？如何在用户不知情的情况下维护网站？
构建一个 .net Web 应用程序，所以我只想知道
- 如果数据库崩溃，Web 应用程序会发生什么情况？
- 如何在用户不知道发生了什么的情况下维护网站？
- 如何处理用户输入的数据？
- 假设我使用状态管理，我可以通过什么方式保存数据？
Building a .net web application, so I just want to know
- what happens to web application if database crashes?
- how to maintain site without user knowing what happened?
- how to handle the data entered by user?
- say if I use state management, in what way can I preserve data?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这完全取决于你付出了多少努力；例如，您可以启用数据库故障转移，这往往很昂贵（第二台服务器、许可证等），但可以非常快速地恢复到该对。您可以对您的应用程序进行编码，以便在内存中（如果您的应用程序回收，这会变得很棘手）或在独立存储中执行某些操作。
这里最常见的选择是务实的：我们需要一个数据库（无论是sql、nosql还是其他什么；一些中央数据存储库）；如果数据库服务器离线，应用程序也会离线。您应该希望数据库层具有良好的正常运行时间；您最好花时间尝试了解如何提高正常运行时间。
只读应用程序的另一个选择是在每个应用层服务器上保留数据库的副本，并增量更新。当应用程序服务器启动时，本地数据库（通常）也启动。
It all depends on how much effort you go to; for example, you could enable database failover, which tends to be expensive (second server, license, etc) but has a very quick recovery onto the pair. You could code your app to do something either in-memory (which gets tricky if your app recycles), or to an independent store.
The most common choice here is pragmatic: we need a DB (whether that is sql, nosql, or whatever; some central data repository); if the DB server goes offline, so does the app. You should be looking to have very good uptime on your DB tier; your time would be better spent trying to see how to improve that uptime.
Another choice for read only applications would be to keep a copy of the DB on each app-tier server, and update incrementally. When the app server is up, so (generally) is the local DB.
正如 Marc 所说，这是一件大事，说实话，我不会依赖 Stack Overflow 上陌生人的知识来形成意见。一般来说，现在的硬件等都相当可靠，并且只需花费相对较少的钱，您就可以实现非常高水平的可用性（RAID 驱动器、NAS 存储等）。如果您需要比通过此途径获得的更高水平的可用性，那么您就进入了专业领域 - 您需要以前做过这件事的人的建议。它的成本也很高——从 99.9% 的正常运行时间提高到 99.99% 很容易使解决方案的成本翻倍。半心半意的措施往往会让事情变得更糟，而不是更好，因为它会增加基础设施和代码的复杂性。复杂性是错误存在的地方，错误比硬件故障更有效地降低可用性。
话虽如此......
这一切都取决于您的应用程序的数据密集程度、应用程序的可缓存程度、数据的复杂程度等。
您可以查看集群数据库 - 在许可/硬件和 DBA 方面都很昂贵时间，但理论上您可以跨多个数据中心进行集群，获得接近 100% 的正常运行时间。
您可以考虑消息传递解决方案，而不是直接访问数据库；消息队列解决方案（微软有一个）是一种与标准“直接与数据库对话的 ASP.Net 应用程序”完全不同的应用程序架构方式，但可以处理大量数据，并提供非常高的故障转移保证。
您可以查看缓存层 - 将所有数据都存储在缓存中可能会让您保持工作站点的错觉，即使底层数据库已关闭。
As Marc says, this is a big deal, and to be honest, I wouldn't rely on knowledge from strangers on Stack Overflow to form an opinion. Broadly speaking, hardware etc. are pretty reliable these days, and for relatively little money, you can achieve a very high level of availability (RAID drives, NAS storage, etc.). If you need higher levels of availability than you can achieve through this route, you're into specialist territory - you want the advice of someone who's done it before. It's also expensive - to go from 99.9% up time to 99.99% can easily double the cost of the solution. Halfhearted measures tend to make things worse, rather than better, by creating additional complexity in both infrastructure and code. Complexity is where the bugs live, and bugs reduce availability more effectively than hardware failure.
Having said that....
It all depends on how data-intensive your application is, how cacheable the application is, how complex the data is etc.
You can look at a clustered database - expensive, both in terms licensing/hardware and DBA time, but theoretically you could cluster across multiple data centres, getting close to 100% up time.
You can look at a messaging solution, rather than direct database access; message queuing solutions (Microsoft has one) are a fundamentally different way of architecting applications from the standard "ASP.Net app talking direct to a database", but can deal with huge volumes, and provide very high fail-over guarantees.
You can look at caching layers - having all your data in a cache might allow you to maintain the illusion of a working site even if the underlying database is off the air.