发到 API 的请求是突发型的,大约 30 秒来一波。后台对这些请求会做一些耗时的操作(图片处理),每个请求需要一个只支持单请求的程序处理 0.5~1 秒左右
目前的排队策略是 API 本身有一个不限时的队列,后面接 Haproxy ,设置的连接超时是 25 秒( 25 秒内必须找到空闲的服务程序),同时 API 对 Haproxy 有 1.5 倍服务程序数量的并发限制防止突发大量请求时有太多失败,类似限流
不知道有没有什么比较合理的排队策略。这个策略是一点点进化过来的,但是感觉不太好。是不是在 API 不限流、把 Haproxy 的连接超时加长,然后监控 Haproxy 的队列长度和排队时间比较合理?
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.