在数据库驱动的 Web 应用程序中，当数据库不可用时用户应该看到什么？
如果 Web 应用程序依赖数据库来提供动态内容，并且该内容由于任何原因（数据库服务器关闭等）不可用，那么处理这种情况的首选方法是什么？
- 将访问者重定向到自定义 404 页面？
- 无论如何显示页面，但包含某种错误消息，否则内容会在哪里？
- 显示具有静态内容的相关页面？
- 其他？
我知道应该进行正确的错误日志记录并通知网站管理员和/或系统管理员。我最感兴趣的是最终用户在这种情况下应该看到的最佳实践。
If a web application relies on a database to serve dynamic content and that content is unavailable for whatever reason (database server down, etc.), what is the preferred method for handling this scenario?
- Redirect the visitor to a custom 404 page?
- Display the page anyway but include some sort of error message where the content would otherwise be?
- Display a related page that has static content?
- Other?
I understand that proper error logging should occur as well as notifying the webmaster and/or sysadmin. I'm mostly interested in best practices for what the end user should see in this situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
#3 如果可以的话（例如每 20 分钟拍摄一次动态内容的快照），但要清楚地表明截至 <时间> 为止它是静态内容。系统问题解决后将立即刷新。
#2 如果你不能，只要错误是人类可读的，而不是从 Java 或类似的异常的堆栈跟踪的文字重新打印。
#3 if you can (e.g. a snapshot of dynamic content taken every 20 mins), but make it crystal clear that it's static content as of <time> and will be refreshed as soon as system issues are resolved.
#2 if you can not, as long as the error is human readable and not a literal re-print of an exception's stack trace from Java or somesuch.
无论您做什么，不要返回 404 - 您的应用程序可能无法正常工作，但您不想给人留下 URL 不正确的印象。除此之外，这可能会对您网站的搜索引擎优化产生负面影响。
如果您要返回 200 以外的某些 HTTP 状态，那么我建议使用 503“服务不可用”响应。这更表明应用程序出现临时故障，而不是 HTTP 请求出现问题。
Whatever you do, DON'T return a 404 - your application may not be working properly, but you don't want to give the impression that the URL is incorrect. Aside from anything else, this could have a negative impact on your site's SEO.
If you're going to return some HTTP status other than 200, then I'd recommend a 503 "Service Unavailable" response. This is more indicative of a temporary fault with the application, rather than something being wrong with the the HTTP request.
我认为这取决于整个页面的内容与数据库的联系程度。例如，在我们的网络应用程序中，如果数据库发生故障，则无法进行身份验证；我们唯一的手段是自定义错误屏幕，其效果是“我们现在遇到了问题；稍后再过来”。
现在;如果动态内容类似于大多数静态文件之上的当天引用，则用简单的错误消息代替内容；或者一起省略动态内容也是适当的。
所以;这取决于页面提供什么服务，以及它是否可以在没有后端的情况下提供任何有用的东西。
I think that depends on how tied to the database the content of the entire page is. For example, in our web apps, if the database is down then there's no method of authentication; our only resort would be a custom error screen to the effect of 'We're having problems now; stop by again later'.
Now; if the dynamic content is similar to a quote of the day on top of a mostly static file, then a simple error message in place of content; or omission of dynamic content all together would be appropriate.
So; it depends on what service the page provides, and whether or not it can provide anything useful without the backend.
我认为#3 可能是最好的，但并不总是可行。如果不可能，某种“技术困难，请稍候......”可能是最好的（显然，您可以将措辞更改为更好的内容）。只是避免实际打印 ERROR: ERR_123/SIGSEGV！ （或类似的东西）用大红色字母。它会让用户认为您的应用程序已损坏，他们可能不会再回来。
I think #3 is probably the best, but not always feasible. If that's not possible, some sort of "Technical difficulties, Please stand by..." might be best (obviously, you can change the wording to something better). Just avoid actually printing ERROR: ERR_123/SIGSEGV! (or something like that) in big red letters. It makes users think your app is broken and they may not come back.