现在正在玩ImageResizer，尝试做某事，我无法理解如何去做。
主要是我想坚持使用管道的想法，而不是试图欺骗它。
所以....让我们说，我非常标准地使用ImageResizer，例如： giants_logo.jpg W = 280安培; H = 100 文件giants_logo.jpg 处理请求适用于'w = 280＆amp; h = 100'
的大小调整版本在集群环境中，如果3台计算机提供相同的请求，将会发生什么。 所有3个人最终都会调整大小，然后将他们的缓存版本存储在光盘上的本地文件夹中。我可以利用共享驱动器或其他东西，但这有其自身的局限性。
我要做的是获取已处理的文件，然后将其复制回到提供主要图像的数据库或S3中。
我的想法是......我可能不得不像DiscCache一样编写一些内容，但是使用DB或S3作为后端而不是文件系统会有完全不同的内容。
我意识到缓存的重点是速度，而我所暗示的是否定了这个方面.....但如果我们将事情分层，那就不是这样了。
无论如何，我所关注的是试图跟踪生成的文件，以及避免在多台服务器上进行处理。
我应该考虑一下这条路线的想法来实现这个目标吗？
答案 0 :(得分：0)
TLDR; 当DiskCache 实际停止正常工作时（通常介于1到2千万个独特图片之间），然后切换到CDN（除非它太贵），或者反向代理（除非您的数据集真的太大而无法受到凡人基础设施的约束）。
对于性能不高的便宜的PB级数据集，这是一个很好的计划。但对大多数人来说，现在还为时过早。即使是超过20TB的用户（源图像）仍然使用DiskCache。真。太字节驱动器很便宜。
要完成这项工作，您需要一台Redis中央服务器。 MSSQL不会削减它（至少不是在VM或商用硬件上，我们已经尝试过）。给定Redis服务器，您可以跟踪已完成和存储的内容（甚至可能正在进行中，以实时去除重复工作，如DiskCache所做的那样）。
如果您可以跟踪它，则可以重复使用它，然后您可以将其删除。重复使用将更慢，因为您将网络流量加倍，将结果移动两次。 （但也会随着源映像提取的集群中的服务器数量线性减少）。
如果带宽饱和是您的瓶颈（非常常见），这可能会使性能更差。实际上，除非您的读/写比率是写入和CPU重，否则您可能会看到比单个磁盘缓存下的重复CPU工作更差的性能。
如果您有基础设施来测试它，请将DiskCache放在SAN或共享驱动器上;这将为您提供可预期性能的可靠估计（假设所述驱动器和您的blob存储系统具有可比较的IO性能）。
然而，这是相当多的工作，并且您实际上是复制反向代理功能的一个子集（但性能更差，因为每个响应都必须通过不幸的群集服务器代理，而不是直接假脱机来自磁盘）。
Amazon CloudFront或Varnish可以很好地作为Web场或群集的反向代理/缓存。现在，您对“垃圾收集”过程的控制会有所减少，但......维护的代码也会减少。
还有ARR，但我既没有成功也没有失败的故事。
发给我一个Github链接，我会帮忙。
我很想得到Redis协调的，与云无关的穷人的blob缓存系统。你带来了PB级和基础设施，我会帮你解决整合和麻烦的问题。高效的HTTP代理可能是最难的部分;其余的是国家管理和基本线程。
答案 1 :(得分：0)
您可能希望查看https://github.com/orbyone/Sensible.ImageResizer.Plugins.AzureReader2
上已修改的AzureReader2插件此实现将转换后的图像存储在初始请求的Azure blob容器中，以便后续请求重定向到该副本。