我想这将取决于让这些物品进入 ETag 本身的成本。
我的意思是,用户发送对给定资源的请求;这应该会触发对数据库的检索操作(或其他一些操作)。
如果检索是简单的事情,例如获取文件,那么查询文件统计信息很快,并且不需要在任何地方存储任何东西:文件路径的 MD5 加上它的更新时间就足够了。
如果检索意味着查询数据库,那么这取决于您是否可以在不损失性能的情况下分解查询(例如,用户通过 ID 请求文章。您可能仅从文章表中检索相关数据。因此缓存“命中”将需要对主键进行单个 SELECT。但是缓存“未命中”意味着您必须再次查询数据库,浪费第一个查询 - 或不浪费 - 取决于您的模型)。
如果查询(或查询序列)可很好地分解(并且生成的代码可维护),那么我将再次使用动态 ETag。
如果不是,则主要取决于查询成本和存储 ETag 解决方案的总体维护成本。如果查询成本很高(或输出很庞大)并且 INSERT/UPDATE 很少,那么(并且,我认为,只有这样)使用 ETag 存储辅助列(或表)将是有利的。
至于缓存中间件,我不知道。如果我有一个框架来跟踪我的一切,我可能会说“去做吧”——中间件应该关心和实现上述几点。如果中间件与实现无关(不太可能,除非它是一个剪切和粘贴的 slap-on ......这并非闻所未闻),那么它要么存在“筛选”资源更新的风险,要么可能在更新时调用一些缓存清除 API 过于尴尬。这两个因素都需要根据 ETag 支持提供的负载改进进行评估。
我不认为在这种情况下存在“银弹”。
编辑:在您的情况下,情况 A 和 B 之间几乎没有区别,甚至没有区别。为了能够实现 getUpdatedAt(),您需要将更新时间存储在模型中。
在这种特定情况下,我认为动态、显式计算 ETag(情况 A)会更简单、更易于维护。无论如何都会产生检索成本,而显式计算成本是 MD5 计算的成本,它非常快且完全受 CPU 限制。在我看来,可维护性和简单性的优势是压倒性的。
在一个半相关的注释中,我想到在某些情况下(对数据库的不频繁更新和更频繁的查询),为整个数据库Last-Modified
实现全局时间可能是有利且几乎透明的。如果数据库没有改变,那么无论查询是什么,对数据库的任何查询都无法返回不同的资源。在这种情况下,只需将全局标志存储在某个易于快速检索的位置(不一定是数据库)。例如Last-Modified
function dbModified() {
touch('.last-update'); // creates the file, or updates its modification time
}
在任何UPDATE/DELETE
代码中。然后资源将添加一个标题
function sendModified() {
$tsstring = gmdate('D, d M Y H:i:s ', filemtime('.last-update')) . 'GMT';
Header("Last-Modified: " . $tsstring);
}
通知浏览器该资源的修改时间。
然后,任何对资源的请求If-Modified-Since
都可以通过 304 被退回,而无需访问持久层(或至少保存所有持久资源访问)。(必须)不需要记录级别的更新时间:
function ifNotModified() {
// Check out timezone settings. The GMT helps but it's not always the ticket
$ims = isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])
? strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE'])
: -1; // This ensures the test will FAIL
if (filemtime('.last-update') <= $ims) {
// The database was never updated after the resource retrieval.
// There's no way the resource may have changed.
exit(Header('HTTP/1.1 304 Not Modified'));
}
}
将 ifNotModified() 调用尽可能早地放在资源供应路线中,将 sendModified 尽可能早地放在资源输出代码中,并将 dbModified() 放在数据库在资源方面被显着修改的地方(即,在将访问统计信息记录到数据库时,您可以并且可能应该避免它,只要它们不影响资源的内容)。