请教，缓存HTTP请求

lweiqiang · 2013-05-28T14:49:53+00:00

Hello! On Sun, May 26, 2013 at 11:56 PM, lua初学者 wrote: > > nginx-1.4.1 > lua-nginx-module-0.8.2 > set-misc-nginx-module-0.2...

请教，缓存HTTP请求

lweiqiang

正在设计一个Web Service流控网关，即在API Server前端配置一个透明对业务透明的网关，并通过网关实现对调用方的流控。初步想法是基于openresty来做网关，但是有一些问题还没想清楚，希望跟大家请教：）

流控功能之一是当后端API Server繁忙时，在网关侧通过排队、缓存请求，实现消峰填谷。网关需要对API Server和API的调用方透明。也就是说需要同步缓存和转发请求。当API Server处理能力超限后，网关需要Hold住新到达的连接请求。我现在想到的办法主要有两种：

1）请求到达时检测API Server的并发计数器，如果并发超限，则在请求处理流程里死循环sleep等待，直到API Server空闲转发请求或者请求超时返回错误；

2）请求到达后，把完整的HTTP请求缓存到消息队列，在消息队列的另一端用独立的进程取出HTTP消息并转发。

现在感觉两种思路可能都有些问题：第一种在请求处理逻辑里sleep busy wait，会不会占用很多资源？第二种呢，状态和连接维护又比较复杂

有没有更好的办法呢？

跟大家求教了：）

From William LI

zoom.quiet

在 2013年5月28日下午2:49，Weiqiang <lwei...@gmail.com> 写道：
> 正在设计一个Web Service流控网关，即在API
> Server前端配置一个透明对业务透明的网关，并通过网关实现对调用方的流控。初步想法是基于openresty来做网关，但是有一些问题还没想清楚，希望跟大家请教：）
>
> 流控功能之一是当后端API Server繁忙时，在网关侧通过排队、缓存请求，实现消峰填谷。网关需要对API
> Server和API的调用方透明。也就是说需要同步缓存和转发请求。当API
> Server处理能力超限后，网关需要Hold住新到达的连接请求。我现在想到的办法主要有两种：
>

- 两个想法的确都不是 HTTP 思想的
- 因为你的所谓 "消峰填谷" 只能是对你的后台服务,而不能是外部来的请求
- 因为,互联网的开放的,别人的请求你控制不了
- 但是,可以使用http 的协议原理,进行正当的不处理
    - 可以简单的根据你服务的容量,设定个并发阀
    - 过了,直接弹回请求
    - 或是 302 到其它静态网页,说明状态
    其它的,根本不用考虑...

> 1）请求到达时检测API Server的并发计数器，如果并发超限，则在请求处理流程里死循环sleep等待，直到API
> Server空闲转发请求或者请求超时返回错误；
>
> 2）请求到达后，把完整的HTTP请求缓存到消息队列，在消息队列的另一端用独立的进程取出HTTP消息并转发。
>
> 现在感觉两种思路可能都有些问题：第一种在请求处理逻辑里sleep busy wait，会不会占用很多资源？第二种呢，状态和连接维护又比较复杂
>
> 有没有更好的办法呢？
> 跟大家求教了：）
>
> --
>
> From William LI
>
>
> --
> -- 
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!
俺: http://about.me/zoom.quiet
许: http://creativecommons.org/licenses/by-sa/2.5/cn/

lweiqiang

呵呵，确实有点不互联网了。。

其实我是中国移动的：）

那我就介绍下场景吧：比如发短信，移动对单个号码是有配额限制的。而我们的业务相当于批发了一个号码，然后超售给不同的用户。

用户的请求大量同时到达的话就需要消峰填谷了

网上也搜到一篇文章，跟我遇到的场景有点像：

http://www.igvita.com/2008/05/13/load-balancing-qos-with-haproxy/

这个方案在Nginx后端部署Haproxy，通过Haproxy对连接实现排队。而我们的需求不仅要对连接排队，还要对发往API Server的请求进行排队和计数。正在研究Haproxy手册中，看Haproxy是否能满足需求。

2013/5/28 Zoom.Quiet <zoom...@gmail.com>

在 2013年5月28日下午2:49，Weiqiang <lwei...@gmail.com> 写道：

> 正在设计一个Web Service流控网关，即在API
> Server前端配置一个透明对业务透明的网关，并通过网关实现对调用方的流控。初步想法是基于openresty来做网关，但是有一些问题还没想清楚，希望跟大家请教：）
>
> 流控功能之一是当后端API Server繁忙时，在网关侧通过排队、缓存请求，实现消峰填谷。网关需要对API
> Server和API的调用方透明。也就是说需要同步缓存和转发请求。当API
> Server处理能力超限后，网关需要Hold住新到达的连接请求。我现在想到的办法主要有两种：
>

- 两个想法的确都不是 HTTP 思想的
- 因为你的所谓 "消峰填谷" 只能是对你的后台服务,而不能是外部来的请求
- 因为,互联网的开放的,别人的请求你控制不了
- 但是,可以使用http 的协议原理,进行正当的不处理
- 可以简单的根据你服务的容量,设定个并发阀
- 过了,直接弹回请求
- 或是 302 到其它静态网页,说明状态
其它的,根本不用考虑...

> 1）请求到达时检测API Server的并发计数器，如果并发超限，则在请求处理流程里死循环sleep等待，直到API
> Server空闲转发请求或者请求超时返回错误；
>
> 2）请求到达后，把完整的HTTP请求缓存到消息队列，在消息队列的另一端用独立的进程取出HTTP消息并转发。
>
> 现在感觉两种思路可能都有些问题：第一种在请求处理逻辑里sleep busy wait，会不会占用很多资源？第二种呢，状态和连接维护又比较复杂
>
> 有没有更好的办法呢？
> 跟大家求教了：）
>
> --
>
> From William LI
>
>

> --
>
>

--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!
俺: http://about.me/zoom.quiet
许: http://creativecommons.org/licenses/by-sa/2.5/cn/

--

From William LI

gwill.buzz

在 2013年5月28日下午3:16，Weiqiang <lwei...@gmail.com>写道：

呵呵，确实有点不互联网了。。
其实我是中国移动的：）

那我就介绍下场景吧：比如发短信，移动对单个号码是有配额限制的。而我们的业务相当于批发了一个号码，然后超售给不同的用户。

这么说，就是不关心调用服务的当时返回，只是相当于发起任务？

如果是这样就非常简答了。

用一个队列消息系统就能很好的实现。

用户的请求大量同时到达的话就需要消峰填谷了

网上也搜到一篇文章，跟我遇到的场景有点像：

http://www.igvita.com/2008/05/13/load-balancing-qos-with-haproxy/
这个方案在Nginx后端部署Haproxy，通过Haproxy对连接实现排队。而我们的需求不仅要对连接排队，还要对发往API Server的请求进行排队和计数。正在研究Haproxy手册中，看Haproxy是否能满足需求。

2013/5/28 Zoom.Quiet <zoom...@gmail.com>

在 2013年5月28日下午2:49，Weiqiang <lwei...@gmail.com> 写道：

> 正在设计一个Web Service流控网关，即在API
> Server前端配置一个透明对业务透明的网关，并通过网关实现对调用方的流控。初步想法是基于openresty来做网关，但是有一些问题还没想清楚，希望跟大家请教：）
>
> 流控功能之一是当后端API Server繁忙时，在网关侧通过排队、缓存请求，实现消峰填谷。网关需要对API
> Server和API的调用方透明。也就是说需要同步缓存和转发请求。当API
> Server处理能力超限后，网关需要Hold住新到达的连接请求。我现在想到的办法主要有两种：
>

- 两个想法的确都不是 HTTP 思想的
- 因为你的所谓 "消峰填谷" 只能是对你的后台服务,而不能是外部来的请求
- 因为,互联网的开放的,别人的请求你控制不了
- 但是,可以使用http 的协议原理,进行正当的不处理
- 可以简单的根据你服务的容量,设定个并发阀
- 过了,直接弹回请求
- 或是 302 到其它静态网页,说明状态
其它的,根本不用考虑...

> 1）请求到达时检测API Server的并发计数器，如果并发超限，则在请求处理流程里死循环sleep等待，直到API
> Server空闲转发请求或者请求超时返回错误；
>
> 2）请求到达后，把完整的HTTP请求缓存到消息队列，在消息队列的另一端用独立的进程取出HTTP消息并转发。
>
> 现在感觉两种思路可能都有些问题：第一种在请求处理逻辑里sleep busy wait，会不会占用很多资源？第二种呢，状态和连接维护又比较复杂
>
> 有没有更好的办法呢？
> 跟大家求教了：）
>
> --
>
> From William LI
>
>

> --
>
>

--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!
俺: http://about.me/zoom.quiet
许: http://creativecommons.org/licenses/by-sa/2.5/cn/

--

--

From William LI

--
#xA0;

lweiqiang

需要关心返回啊，要把API Server的response返回给调用方

2013/5/28 G_will <gwil...@gmail.com>

在 2013年5月28日下午3:16，Weiqiang <lwei...@gmail.com>写道：

呵呵，确实有点不互联网了。。
其实我是中国移动的：）

那我就介绍下场景吧：比如发短信，移动对单个号码是有配额限制的。而我们的业务相当于批发了一个号码，然后超售给不同的用户。

这么说，就是不关心调用服务的当时返回，只是相当于发起任务？
如果是这样就非常简答了。

用一个队列消息系统就能很好的实现。

用户的请求大量同时到达的话就需要消峰填谷了

网上也搜到一篇文章，跟我遇到的场景有点像：

http://www.igvita.com/2008/05/13/load-balancing-qos-with-haproxy/
这个方案在Nginx后端部署Haproxy，通过Haproxy对连接实现排队。而我们的需求不仅要对连接排队，还要对发往API Server的请求进行排队和计数。正在研究Haproxy手册中，看Haproxy是否能满足需求。

2013/5/28 Zoom.Quiet <zoom...@gmail.com>

在 2013年5月28日下午2:49，Weiqiang <lwei...@gmail.com> 写道：

> 正在设计一个Web Service流控网关，即在API
> Server前端配置一个透明对业务透明的网关，并通过网关实现对调用方的流控。初步想法是基于openresty来做网关，但是有一些问题还没想清楚，希望跟大家请教：）
>
> 流控功能之一是当后端API Server繁忙时，在网关侧通过排队、缓存请求，实现消峰填谷。网关需要对API
> Server和API的调用方透明。也就是说需要同步缓存和转发请求。当API
> Server处理能力超限后，网关需要Hold住新到达的连接请求。我现在想到的办法主要有两种：
>

- 两个想法的确都不是 HTTP 思想的
- 因为你的所谓 "消峰填谷" 只能是对你的后台服务,而不能是外部来的请求
- 因为,互联网的开放的,别人的请求你控制不了
- 但是,可以使用http 的协议原理,进行正当的不处理
- 可以简单的根据你服务的容量,设定个并发阀
- 过了,直接弹回请求
- 或是 302 到其它静态网页,说明状态
其它的,根本不用考虑...

> 1）请求到达时检测API Server的并发计数器，如果并发超限，则在请求处理流程里死循环sleep等待，直到API
> Server空闲转发请求或者请求超时返回错误；
>
> 2）请求到达后，把完整的HTTP请求缓存到消息队列，在消息队列的另一端用独立的进程取出HTTP消息并转发。
>
> 现在感觉两种思路可能都有些问题：第一种在请求处理逻辑里sleep busy wait，会不会占用很多资源？第二种呢，状态和连接维护又比较复杂
>
> 有没有更好的办法呢？
> 跟大家求教了：）
>
> --
>
> From William LI
>
>

> --
>
>

--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!
俺: http://about.me/zoom.quiet
许: http://creativecommons.org/licenses/by-sa/2.5/cn/

--

--

From William LI

--
sp;

--
sp;

From William LI