这是一个创建于 3045 天前的主题，其中的信息可能已经有所发展或是发生改变。
发到 API 的请求是突发型的，大约 30 秒来一波。后台对这些请求会做一些耗时的操作（图片处理），每个请求需要一个只支持单请求的程序处理 0.5~1 秒左右
目前的排队策略是 API 本身有一个不限时的队列，后面接 Haproxy ，设置的连接超时是 25 秒（ 25 秒内必须找到空闲的服务程序），同时 API 对 Haproxy 有 1.5 倍服务程序数量的并发限制防止突发大量请求时有太多失败，类似限流
不知道有没有什么比较合理的排队策略。这个策略是一点点进化过来的，但是感觉不太好。是不是在 API 不限流、把 Haproxy 的连接超时加长，然后监控 Haproxy 的队列长度和排队时间比较合理？
 |
1
rrfeng 2016-08-25 18:07:58 +08:00
扔进 MQ 里呗……
|
 |
2
surfire91 2016-08-25 18:28:54 +08:00
这类耗时的 API 改成异步处理。
详细点说，比如你这个图片处理的，客户端发送图片，服务端返回已处理的图片，改成两个 api ： 1. 客户端提交要处理图片，服务端将任务放到队列里，先返回一个任务 id 。 2. 客户端拿 1 api 返回的任务 id 来请求，服务端根据任务的处理情况返回（如果待处理，返回待处理，处理完了就返回已处理的图片之类的）。如果客户端拿到待处理的结果，稍后再来请求。 |
 |
3
majik 2016-08-25 18:39:04 +08:00 via iPhone
websocket
|
 |
4
cheneydog 2016-08-25 18:56:41 +08:00
肯定得是异步的，肯定得用一个队列。
|
 |
6
neodooth OP @rrfeng 把 haproxy 当成一个 mq 怎么样，主要的问题还是在怎么可靠地排队、监控队列情况。。。因为我是想不要引入新的模块，后续接替我维护这个系统的人光理解现在的这些代码就已经很费劲。。我们情况也还比较特殊， MQ 不太好接进来，后边那些耗时的服务程序有很多个，完成不同的功能，要改接口的话是个极为繁重的任务而且很可能引入 bug.系统现在已经在生产环境上线，我们也并没有那么强大的运维能力和人力去搞一个完善的测试环境，所以还是想怎么在现有基础上继续进化， API 的队列机制和 Haproxy 的配置还是比较好改的。。。
@surfire91 其实 API 前端的异步、同步倒是问题不大，现在的设计是请求在 2 分钟内返回就可以，改成异步的话我不知道是不是怕同时的连接太多导致资源耗尽？然后这个系统其实是给第三方做的，大面积的改接口并不太可行。这种方式确实在有些情况下很好我们在别的地方的 API 就用到了这种模式，但是这个系统现在已经基本定型了所以。。。。。 可能我没太表达清楚问题，请求方调用 API 的方式没有问题，问题是在于我觉得现在 API 到服务程序之间排队的模式（ API 一个限制并发的队列+Haproxy 连接时间限制）不太好通过监控即时发现请求数量超过处理能力的情况，而请求是脉冲型的特点似乎又让这个需求变得更加扑朔迷离…… |
 |
7
tinyproxy 2016-08-26 08:05:47 +08:00 via iPhone
@neodooth 你要处理慢请求又不想要队列，不想改现有设计，那就横向扩展呗，只要你有足够的实例吞下这些慢请求，没人觉得慢。
|
 |
8
helloworld2010 2016-08-26 18:02:43 +08:00
耗时的异步否？
|
Select Language