CDN缓存对chunked数据的处理

ssdrliu · 2015-08-15T13:12:55+00:00

Hello! On Fri, Aug 14, 2015 at 4:30 PM, Brusseltu wrote: > openresty 什么时候可以添加一些 &...

CDN缓存对chunked数据的处理

ssdrliu

CDN从源站拉取chunked数据，在完全获取文件之前不能得知文件长度，因此不能从缓存响应数据给用户，在高并发的请求下，所有请求回源会造成源站压力。请教各位有什么好招？

jacky

小文件一般不会有这个问题，如果小文件也存在回源压力大的问题，那可能是过期策略，或者CDN的过期策略不合理。

一些比较大的文件，在发布之前，主动推送一遍~~~ 过期时间设置长一些。。基本上也不会有这个问题~



在 8/15/15 13:12, 牧童 写道:

CDN从源站拉取chunked数据，在完全获取文件之前不能得知文件长度，因此不能从缓存响应数据给用户，在高并发的请求下，所有请求回源会造成源站压力。请教各位有什么好招？

agentzh

Hello!

2015-08-15 13:12 GMT+08:00 牧童:
> CDN从源站拉取chunked数据，在完全获取文件之前不能得知文件长度，因此不能从缓存响应数据给用户，在高并发的请求下，所有请求回源会造成源站压力。请教各位有什么好招？
>

CDN 如果不能缓存 chunked 编码的响应则是 CDN 本身的 bug 了。另外，你的描述中让我费解的是，如果 CDN
缓存会命中的话，则对应的请求根本不应该回源，否则就成了 CDN 缓存不命中了（当然了，conditional GET 请求与 304 Not
Modified 响应则是一个例外，但显然这种情况与 chunked 编码没有任何关系）。

Regards,
-agentzh

ssdrliu

感谢大神回复。
现在就是讨论缓存不命中（或缓存失效且非304）的情况，这时需要拉取整个文件更新缓存。
简单粗暴的方法是边回源拉数据响应用户，边更新CDN缓存，但这种做法在并发大的时候，
会造成回源压力很大。
还有一种做法是合并回源，拿一次数据同时响应多个并发请求，不知这种做法如何在不同请求间共享数据？
另外，边响应用户边更新缓存的做法有没有必要分在不同的轻线程里做，同样如何共享数据？

moonbingbing

你的问题是缓存失效的瞬间，会导致很多并发的请求，去回源拉去数据更新到缓存中。也就是缓存失效风暴。

你可以使用resty lock来控制只有一个连接去请求源站的数据，并发的其他请求，用get_stale之类的方法，依然拿过期的数据回去。等回源完成，后面的请求就能拿到新的缓存数据了。

在 2015年8月16日下午11:05，牧童 <ssd...@gmail.com>写道：

感谢大神回复。
现在就是讨论缓存不命中（或缓存失效且非304）的情况，这时需要拉取整个文件更新缓存。
简单粗暴的方法是边回源拉数据响应用户，边更新CDN缓存，但这种做法在并发大的时候，
会造成回源压力很大。
还有一种做法是合并回源，拿一次数据同时响应多个并发请求，不知这种做法如何在不同请求间共享数据？
另外，边响应用户边更新缓存的做法有没有必要分在不同的轻线程里做，同样如何共享数据？

--

WenMing

Our Book: OpenResty Best Practices

agentzh

Hello!

2015-08-17 10:28 GMT+08:00 Ming:
> 你的问题是缓存失效的瞬间，会导致很多并发的请求，去回源拉去数据更新到缓存中。也就是缓存失效风暴。
> 你可以使用resty
> lock来控制只有一个连接去请求源站的数据，并发的其他请求，用get_stale之类的方法，依然拿过期的数据回去。等回源完成，后面的请求就能拿到新的缓存数据了。
>

是的，这是所谓的 "dog-pile effect"，与 chunked 编码和 Content-Length 响应头没有任何关系。

如果使用的是 ngx_proxy 模块，则该模块提供了现成的 proxy_cache_lock 指令和
proxy_cache_use_stale 指令可以用于解决此问题。如果是 ngx_lua 模块，则通过 lua-resty-lock 和
ngx.shared.DICT 的 get_stale 之类的东西来搞。

Regards,
-agentzh