我写了一个快速的Python服务器来服务重采样的图像。 例如，URL可能类似于http://images.domain.com/resample/100x100/9f362e1994264321.jpg 。 重新采样图像是昂贵的，caching层是必要的。 这似乎是一个nginx反向代理将是一个很好的select， 这里和这里似乎是好的地方开始。
但是，有一个问题。 有数百万的图像，所以通过在文件系统中存储http://images.domain.com/resample/100x100/9f362e1994264321.jpg作为/home/nginx/cache/resample/100x100/9f362e1994264321.jpg （或类似的东西），最终cache/resample/100x100/将有数以百万计的文件，这将使文件查找非常低效。
我在处理这个问题的同时通过将原始图像分布在许多子目录中来存储原始图像，例如9f/36/9f362e1994264321.jpg 。 但是，我不知道我怎么可能做同样的nginx。 我可以改变url做同样的事情，如果这是唯一的解决scheme，我宁愿保持url尽可能漂亮。
我可以用nginx做这个吗？ 如果不用nginx，我可以做点别的，比如清漆吗？
相反，谷歌一些不相干的链接，你一定要阅读关于ngx_http_proxy_module.html的文档。
指令proxy_cache正是你所需要的。 configuration应该看起来像这样。
http { # ... proxy_cache_path /var/www/cache levels=1:2 keys_zone=imgcache:10m max_size=1000m inactive=720m; proxy_temp_path /var/www/cache/tmp; # ... server { # ... location /resample { proxy_pass http://bla.bla.my.backend; proxy_cache imgcache; #proxy_cache_key $scheme$proxy_host$request_uri; #proxy_cache_valid 200 302 60m; #proxy_cache_valid 404 10m } # ... } }
在/var/www/cache文件夹下将创build两个级别的目录结构。 并且http://mysite.com/resample/dir/file.jpg的caching响应将被保存为proxy_cache_key值的md5。 例如，如果取消注释#proxy_cache_key $scheme$proxy_host$request_uri; 以上，响应将被caching到文件/ var / www / cache / f / 08 / 8db24849a311cc3314955992686d308f
由于MD5 ("http://bla.bla.my.backend/resample/dir/file.jpg") = 8db24849a311cc3314955992686d308f和级别= 1：2翻译为dir结构，计数从最后一个字符，… 08f – > F / 08 / md5value
这将使文件查找非常低效。
这听起来像是不成熟的优化。
您尚未提供有关正在运行的操作系统的信息。 既然你提到了Varnish，我认为这是Unix的一些味道。 假设它是Linux（尽pipe大多数这也适用于其他操作系统）….
你真的测量过它，并将其与path重写方法进行比较？ 如果你看到一个退化，那么你很可能会运行一个非常旧的文件系统（或通过部分修补升级的文件系统）。 有了ext4或BTRFS，我不希望看到可测量的差异。
但是，这是相当重要的。 反向代理知道他们可以caching大量文件 – 而且不一定将URLpath直接映射到文件系统path。
你将遇到由高速cachingpipe理的大量文件的问题，但是这些都与VFS /方法有关。 减lessvfs_cache_pressure应该有所帮助。