返回 HTTP 503 以响应数据库死锁是不是合适？

Posted 2023-03-10

技术标签:

【中文标题】返回 HTTP 503 以响应数据库死锁是不是合适？【英文标题】：Is it appropriate to return HTTP 503 in response to a database deadlock?返回 HTTP 503 以响应数据库死锁是否合适？ 【发布时间】：2013-05-13 18:47:24 【问题描述】：

当请求的操作导致数据库死锁时，服务器返回503 ("Service Unavailable") 是否合适？

这是我的推理：

最初我尝试避免数据库死锁，但我遇到了https://***.com/a/112256/14731 接下来，我尝试在服务器端重复请求，但遇到了Java Servlets: How to repeat an HTTP request?。从技术上讲，我可以缓冲请求实体，但可扩展性会受到影响，并且客户端更有可能看到503 Service Unavailable。

看成：

要求客户重复操作更容易。无论如何，他们需要能够处理503 Service Unavailable。数据库死锁相当少见。

我倾向于这个解决方案。你怎么看？

更新：如果您愿意，我认为返回503 ("Service Unavailable") 仍然是可以接受的，但我不再认为它在技术上是必需的。见https://***.com/a/17960047/14731。

【问题讨论】：

即使您在生产环境中对此进行编程，您仍可能以超时结束，这将导致您的负载平衡代理向客户端发送 504。 @agilevic，你是什么意思？你是说我需要确保将超时死锁配置为使用较小的超时值来避免HTTP 504？数据库死锁的持续时间可能比负载均衡器的超时时间长，因此会阻塞响应。如果您能够在超时之前检测到死锁，您可以使用 503 响应客户端 - 一个明智的选择。 【参考方案1】：

我觉得只要整个事务回滚或者请求是幂等的就可以了。

【讨论】：

【参考方案2】：

我认为语义上 409 Conflict 是一个更好的选择 - 基本上，如果您遇到死锁，则会争用某些资源，因此无法完成操作。

现在根据死锁的原因，如果再次提交请求可能不会成功，但对于任何事情都是如此。

对于 503，作为客户端，我会实施某种退避/断路器操作，因为系统受速率限制，而 409 与特定请求相关。

【讨论】：

【参考方案3】：

刚来这里问同样的问题，但没有明确的答案。

可以接受 503，但可能无法正确解释 409 也可以，但在我的情况下不行（因为多个资源最终可能会为同一 URL 返回此错误）

在我的情况下，我最终在同一个 URL 上返回了 307 重定向。

客户端将自动“重试”并且第二次调用有效，因为资源仅在其初始创建期间引发死锁。