ruby-on-rails - 请求和响应处理之间的 HTTP 断开连接/超时

Question

假设以下场景:

1. 客户端正在向服务器发送 HTTP POST
2. 请求有效且 已被服务器处理。数据已插入数据库。
3. Web 应用程序正在响应客户端
4. 客户端遇到超时 并且看不到 HTTP 响应。

在这种情况下，我们会遇到以下情况: - 客户不知道他的数据是否有效以及是否被正确插入 - Web 服务器(rails 3.2 应用程序)没有显示任何异常，无论它是否在 apache 代理后面

我在 HTTP 文档中找不到如何处理这种情况。我的问题是:

a) 客户应该期望他的数据可能已经被处理了吗？ (然后尝试使用 GET 请求来检查数据是否已提交)

b) 如果不是 (a) - 服务器应该检测到它吗？有没有可能在 rails 中做到这一点？在这种情况下，可以撤销更改。在这种情况下，我希望 Rails 应用程序有某种期望，但没有...

Answer 1

HTTP is a stateless protocol :根据定义，这意味着您无法在客户端知道 http 动词 POST 是否成功。

Web 应用程序使用一些技术来克服此 HTTP“功能”。它们包括。

• server side sessions
• cookies
• 表单中的隐藏变量

但是，这些都不能真正帮助您解决问题。当我过去遇到这些类型的问题时，它们几乎总是 the server taking too long to process the web request 的结果.

我在不眠之夜对自己耳语的一句话非常棒:

“The web request is a scary place, you want to get in and out as quick as you can” - Rick Branson

您希望在 100 - 500 毫秒内进入和退出您的 Web 请求。您满足了这些数字，您将拥有一个运行良好/与网络服务器配合良好的网络应用程序。

为此 我建议您调查您的帖子花费了多长时间，并弄清楚如何缩短这些请求。如果您在执行 dbms 插入之前在服务器端进行了一些严肃的处理，您应该考虑将这些处理交给某种任务/队列系统。

“严肃处理”的一个示例可能是某种图片上传，可能在上传后进行一些图片处理。 任务分配和排队解决方案的示例是:RabbitMQ和 Celery

您的问题的示例解决方案可能是:

1. 将您的一部分数据插入 dbms(或更快一些 NoSQL 解决方案)
2. 将昂贵的处理工作交给后台任务。
3. 返回给用户/网络客户端。 (即使在后台任务仍在运行)
4. 使用 ( polling, streaming or websockets ) 收听最终响应 这一步并非易事，但最终结果非常值得付出努力。

收紧这些网络请求，您的客户收不到响应的情况将很少见。

在客户未收到数据的罕见日子里:您如何防止多个帖子...我对您的数据一无所知。但是，您可以执行一些与架构相关的操作来唯一标识您的帖子。即在服务器端确定数据是 update 还是 create。

This answer涵盖了您可以使用的一些轮询/流式传输/websockets 技术。