Sitecore 在发布媒体项目时如何处理竞争条件?
设想:
- 站点访问者正在下载具有 500mb mpg 文件(存储为 blob)的非版本化媒体项目。
- 下载最多需要几分钟,最坏的情况可能以小时为单位(如果它们处于低带宽连接上)。
- 当用户下载时,作者在媒体项目上上传新版本的 mpg 并发布。
会发生什么,为什么?
其他变体包括: 媒体项目上的安全设置更改为阻止访问者下载访问 媒体项目被删除并发布更改
我猜在所有这些情况下,下载都会中止,但如果是这样,服务器会发送什么响应?
Sitecore 在发布媒体项目时如何处理竞争条件?
设想:
会发生什么,为什么?
其他变体包括: 媒体项目上的安全设置更改为阻止访问者下载访问 媒体项目被删除并发布更改
我猜在所有这些情况下,下载都会中止,但如果是这样,服务器会发送什么响应?
我没有确切的答案,但 Sitecore 将 blob 资产缓存在文件系统下,/App_Data/MediaCache/
因此现有资产可能仍在该缓存中。我不确定 Sitecore 的媒体缓存机制是如何工作的,但我敢打赌,一旦资产完全存在,它会在对新资产的下一个请求中清除/重新缓存。
只是一个猜测。也许反编译内核以找到处理缓存媒体的代码。
(不是真正的答案..只是评论对于盒子来说太大了:P)
这是一个非常有趣的问题。Sitecore 的媒体性能很大程度上是通过将副本缓存到磁盘并在后续请求中从那里交付(也用于缓存原件的缩放副本,例如缩略图等)来完成的。一旦以某种方式编辑原始项目然后重新发布,文件就会被刷新。
我不确定(并且很感兴趣)这将如何影响大文件,因为我认为很多人认为媒体可能是较小的文件,例如图像或 pdf 等,如果损坏,用户只会重新请求,以及这如何影响当前的文件在项目本身更新时进行流式传输。我确信当时的很多工作是 IIS/ASP.NET 流而不是 Sitecore 本身。
我不确定 Sitecore 的缓存是否会保护/屏蔽这种情况,但这应该非常简单,可以使用更大的媒体文件进行测试。对结果感兴趣(因为我亲自交付的较大文件是由 CDN 或专门的流媒体合作伙伴完成的)
这不是一个明确的答案,我同意斯蒂芬关于专门的流媒体合作伙伴的看法。我想知道这样的系统如何处理这个问题。
Sitecore 似乎为每个发布和访问的修订创建了一个新的媒体缓存文件,因此 HTTP 传输可以在系统写入新文件时继续读取旧文件。如果禁用缓存,不确定是否/如何工作(我没有尝试禁用缓存)。否则,在读取时尝试写入可能会被阻止或干扰读取。
请注意,即使您没有版本,您也会获得一个新的修订 ID。并且它可能是导致新缓存条目的发布,而不是新修订的出现。