请教 API 服务排队策略

2016-08-25 17:19:29 +08:00
 neodooth

发到 API 的请求是突发型的,大约 30 秒来一波。后台对这些请求会做一些耗时的操作(图片处理),每个请求需要一个只支持单请求的程序处理 0.5~1 秒左右

目前的排队策略是 API 本身有一个不限时的队列,后面接 Haproxy ,设置的连接超时是 25 秒( 25 秒内必须找到空闲的服务程序),同时 API 对 Haproxy 有 1.5 倍服务程序数量的并发限制防止突发大量请求时有太多失败,类似限流

不知道有没有什么比较合理的排队策略。这个策略是一点点进化过来的,但是感觉不太好。是不是在 API 不限流、把 Haproxy 的连接超时加长,然后监控 Haproxy 的队列长度和排队时间比较合理?

3082 次点击
所在节点    程序员
8 条回复
rrfeng
2016-08-25 18:07:58 +08:00
扔进 MQ 里呗……
surfire91
2016-08-25 18:28:54 +08:00
这类耗时的 API 改成异步处理。
详细点说,比如你这个图片处理的,客户端发送图片,服务端返回已处理的图片,改成两个 api :
1. 客户端提交要处理图片,服务端将任务放到队列里,先返回一个任务 id 。
2. 客户端拿 1 api 返回的任务 id 来请求,服务端根据任务的处理情况返回(如果待处理,返回待处理,处理完了就返回已处理的图片之类的)。如果客户端拿到待处理的结果,稍后再来请求。
majik
2016-08-25 18:39:04 +08:00
websocket
cheneydog
2016-08-25 18:56:41 +08:00
肯定得是异步的,肯定得用一个队列。
iyaozhen
2016-08-25 19:41:44 +08:00
@surfire91 赞同,客户端请求之后拿着唯一 id 来轮训。这样比较好。
neodooth
2016-08-26 01:18:20 +08:00
@rrfeng 把 haproxy 当成一个 mq 怎么样,主要的问题还是在怎么可靠地排队、监控队列情况。。。因为我是想不要引入新的模块,后续接替我维护这个系统的人光理解现在的这些代码就已经很费劲。。我们情况也还比较特殊, MQ 不太好接进来,后边那些耗时的服务程序有很多个,完成不同的功能,要改接口的话是个极为繁重的任务而且很可能引入 bug.系统现在已经在生产环境上线,我们也并没有那么强大的运维能力和人力去搞一个完善的测试环境,所以还是想怎么在现有基础上继续进化, API 的队列机制和 Haproxy 的配置还是比较好改的。。。

@surfire91 其实 API 前端的异步、同步倒是问题不大,现在的设计是请求在 2 分钟内返回就可以,改成异步的话我不知道是不是怕同时的连接太多导致资源耗尽?然后这个系统其实是给第三方做的,大面积的改接口并不太可行。这种方式确实在有些情况下很好我们在别的地方的 API 就用到了这种模式,但是这个系统现在已经基本定型了所以。。。。。

可能我没太表达清楚问题,请求方调用 API 的方式没有问题,问题是在于我觉得现在 API 到服务程序之间排队的模式( API 一个限制并发的队列+Haproxy 连接时间限制)不太好通过监控即时发现请求数量超过处理能力的情况,而请求是脉冲型的特点似乎又让这个需求变得更加扑朔迷离……
tinyproxy
2016-08-26 08:05:47 +08:00
@neodooth 你要处理慢请求又不想要队列,不想改现有设计,那就横向扩展呗,只要你有足够的实例吞下这些慢请求,没人觉得慢。
helloworld2010
2016-08-26 18:02:43 +08:00
耗时的异步否?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/301739

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX