在数据库死锁的情况下，返回HTTP 503响应是否合适？

Question

当请求操作导致数据库死锁时，服务器返回503（"服务不可用"）是否合适？

以下是我的推理：

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

鉴于：

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

我倾向于这个解决方案。你认为呢？

更新: 我认为如果您希望的话，返回503（"服务不可用"）仍然可以接受，但我不再认为这是技术上必需的。请参见https://stackoverflow.com/a/17960047/14731。

- Gili

---

即使您在生产环境中编写此代码，仍可能出现超时，这将导致负载均衡代理向客户端发送504错误。 - Victor Olex

@agilevic，你的意思是什么？你是说我需要确保死锁超时配置为使用较小的超时值以避免HTTP 504吗？ - Gili

数据库死锁可能持续时间比负载均衡器的超时时间更长，从而阻塞响应。如果您能在超时之前检测到死锁，则可以使用503向客户端响应-这是一个明智的选择。 - Victor Olex

Answer 1

我认为语义上409错误更好-基本上，如果您遇到死锁，则某些资源存在争用，因此操作无法完成。

现在，根据死锁的原因，如果再次提交请求，则该请求可能无法成功完成，但这对任何事情都是正确的。

对于503错误，作为客户端，我将实施某种回退/断路器操作，因为系统存在速率限制，而409与特定请求相关联。

- Paul Hatcher

Answer 2

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

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

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

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

请注意这可能会导致无限循环

- Romuald Brunet

Answer 3

我认为只要整个事务被回滚或请求是幂等的，那么这就没问题。

- Miguel