proxy_cache_lock官方解释

Nginx.org 官方的 Maxim Dounin 对于proxy_cache_lock的答复

Hello!

On Mon, Jun 30, 2014 at 11:10:52PM -0400, Paul Schlie wrote:

being seemingly why proxy_cache_lock was introduced, as you initially suggested.
Again: responses are not guaranteed to be the same, and unless
you are using cache (and hence proxy_cache_key and various header
checks to ensure responses are at least interchangeable), the only
thing you can do is to proxy requests one by one.

If you are using cache, then there is proxy_cache_key to identify
a resource requested, and proxy_cache_lock to prevent multiple
parallel requests to populate the same cache node (and
“proxy_cache_use_stale updating” to prevent multiple requests when
updating a cache node).

In theory, cache code can be improved (compared to what we
currently have) to introduce sending of a response being loaded
into a cache to multiple clients. I.e., stop waiting for a cache
lock once we’ve got the response headers, and stream the response
body being load to all clients waited for it. This should/can
help when loading large files into a cache, when waiting with
proxy_cache_lock for a complete response isn’t cheap. In
practice, introducing such a code isn’t cheap either, and it’s not
about using other names for temporary files.


Maxim Dounin
http://nginx.org/

Nginx proxy_cache_lock

Nginx provides powerful proxy cache capability.

One of the powerful directive is proxy_cache_lock, which work similar to collapsed forwarding in squid, enables multiple requests for the same URI to be processed as one request. For some specific cases like big size static content, it can optimize the cache hit rate and reduce upstream request to 1.

Nginx提供强大的代理缓存能力。

proxy_cache_lock指令的强大之一,类似collapsed forwarding in squid,能够使多条相同URI的请求处理为一条请求。用于一些特殊的场景,像大量的静态内容,proxy_cache_lock能优化缓存命中率,缩减(合并)上游请求至1个。

proxy_cache_lock出现在什么场景

此处引用案例的文字和图片均来源原微信公众号:性能与架构,翻译作者:杜亦舒。
文章标题:Facebook 直播是如何承受海量压力的?

FaceBook缓解高并发的架构

应用程序和网站的性能至关重要,决定了互联网产品的生存。如何让应用程序或者网站的性能达到最好,或者能够快速响应。优化方案很多,比如增加CDN,缓存静态资源,压缩静态资源等等。

在浏览器和应用服务器之间,存在多种“潜在”缓存,如:客户端浏览器缓存、中间缓存、内容分发网络( CDN )和服务器上的负载平衡和反向代理。缓存,仅在反向代理和负载均衡的层面,就对性能提高有很大的帮助。缓存还可以提高负载平衡器、反向代理和应用服务器前端 web 服务的性能。

FaceBook LIVE架构

且看FaceBook对缓存的使用。Facebook 在 2016 年底时的月活用户数有 1860 万,Facebook live 的压力很大,有大量的人开直播,有大量的用户观看直播。整体来看,直播的挑战在于:

  1. 需要能够同时支持数百万的直播流
    2。 对于同一个直播流,需要能够支持数百万的用户
    而且直播有一个非常明显的特点,就是非常集中的流量峰值,例如某个名人开了直播,很快就会有大量的用户进来,产生巨大的流量峰值。

FaceBook的对于海量压力从架构上做了优化,增了Edge Cache、Origin Server两级缓存,当前面的缓存不能命中的时候,才落地到Streaming Server。这个架构极大的减少了 Streaming Server 处理的请求数量,例如有5个请求顺序达到 Edge Cache,只有第一个请求走遍了全程,从 Streaming Server 拿数据,其他4个请求都可以直接从 Edge Cache 中拿到数据。

这个架构虽然很有效,但是还有一定的问题,当有多个并发请求时,多个请求同时达到Edge Cache,都要请求某个相同的数据包,如果没有命中,那么这几个请求则由同时请求Origin Server。同样,可能相同的问题发生在Origin Server中,从而相同的请求转发到了Streaming Server。

FaceBook的解决方案

Facebook 的处理办法非常简单,当有多个请求同时到达 Edge Cache,如果他们请求的是相同的数据包,那么就把他们归为一组,放到一个请求队列中,并且只让一个进入到 Origin Server(称为请求合并),当响应回来后,先缓存,然后返回给队列中的各个请求

这个策略同样也在 Origin Server 层进行应用,如果多个 Edge Cache 并发请求相同数据,也会进行合并,只有一个会进入 Streaming Server

这样就很好的解决了并发产生的问题

在 Nginx 中,请求合并可以这样设置:

1
2
proxy_cache_lock = on

负载均衡
还有一点很重要,对 Edge Cache servers 进行负载均衡

在流量高峰期,Edge Cache server 的压力会很大,需要使用负载均衡器对请求进行调配,例如离你最近的那个 Edge Cache 已经在处理20万请求,那么负载均衡器就会把你分配到离你稍远一点,但处理压力较小的按个 Edge Cache

负载均衡器会根据距离与压力进行综合权衡,把用户分配到最合适的 Edge Cache server。

总结

当 proxy_cache_lock 被启用时,当多个客户端请求一个缓存中不存在的文件(或称之为一个 MISS ),只有这些请求中的第一个被允许发送至服务器。其他请求在第一个请求得到满意结果之后在缓存中得到文件。如果不启用 proxy_cache_lock
,则所有在缓存中找不到文件的请求都会直接与服务器通信