如何处理长时间运行的服务器响应以及将其视为停滞连接的负载均衡器

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《如何处理长时间运行的服务器响应以及将其视为停滞连接的负载均衡器》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

案例/假设：

1. 有一个由其他人编写的服务器。
2. 此服务器有一个端点 get /api/watch。
3. 此端点是纯 http/1.1
4. 此端点将写入如下事件

   {type:"foo", message:"bar"}

   一旦它们出现就发送到响应流（每行一个事件，然后刷新）。
5. 有时，该服务器每秒将事件写入输出，有时每 15 分钟一次。
6. 在我的客户端和此服务器之间有一个第三方负载均衡器，如果连接超过 60 秒没有任何操作，该连接就会假定该连接已失效，并会在不关闭连接的情况下删除该连接。
7. 客户端使用简单的 golang 编写，只需向此端点发出 get 请求即可。
8. 一旦连接被 lb 标记为失效，客户端（curl 也会发生同样的情况）就不会收到 lb 已删除连接的通知，并且仍在等待在 get 请求的响应中接收内容.

那么：我有什么可能来处理这种情况？

什么是不可能的：

1. 修改服务器。
2. 使用其他服务器。
3. 使用除此端点及其编写方式之外的其他内容。
4. 修改负载均衡器。
5. 使用另一个负载均衡。
6. 将负载均衡器排除在连接之外。

解决方案

对于基本 HTTP 来说，15 分钟是一个令人难以置信的长静默期——可能更适合 WebSocket。如果没有更改协议，您应该能够调整负载均衡器的超时时间（很难说，因为您没有指定 LB 是什么）以更好地适合您的用例，但不是所有负载均衡器允许最多 15 分钟的超时。如果您无法更改协议并且无法将超时设置得足够高，则您必须经常从服务器发送保活消息（刚好比超时时间短，所以可能是 55 秒）使用您当前的配置，或者稍微小于您可以在 LB 上设置的最高超时期限）。这必须是客户端知道要丢弃的内容，例如 {"type": "keepalive"} - 在客户端很容易识别为用于保持活动目的的“假”消息。

到这里，我们也就讲完了《如何处理长时间运行的服务器响应以及将其视为停滞连接的负载均衡器》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！