我是否可以使用时间戳参数来实现缓存失效？

Question

我正在考虑在缓存响应中传递时间戳值的方案，然后将其发送回服务以执行缓存无效。我想知道这是否是一个有效的方法。这是一种常见的做法吗？

例如，如果我有一个返回"Foo“记录的服务，这是DB查找和计算的组合。假设Foo是用密钥标识的。为了加快速度，我想保持一个本地缓存的结果。

问题是，跨服务器银行，本地缓存将失去同步，因为计算结果将随着时间的推移而变化。

所以我的想法是：

• 对于请求，计算Foo
• 使用“截至”时间戳将Foo存储在本地缓存中。
• 返回Foo和"as of“时间戳
• 当客户端想要获取Foo时，它会传递密钥和"as of“时间戳。
• 如果服务器在本地缓存中找到键，而缓存中的"as of“时间戳比"as of”参数更新，则返回带Foo、key和"as of“时间戳的缓存Foo。
• 否则，重新计算Foo，缓存它，并返回(新)Foo、key和(new)“作为”时间戳。

客户端需要同时跟踪键和“截至”时间戳，但实际上它将控制服务实例何时刷新其本地缓存，而不需要服务实例相互交谈或一些后端存储进行协调。

如果客户端希望强制缓存刷新，它可以传递最大值的“截至”值，这将强制对其命中的任何服务实例进行刷新。

当然，我可以在服务前面放置一个缓存层，也可以将结果保存在分布式缓存中。这些解决方案也有自己的数据复制和过期问题。但是为了这个问题，我真的想考虑本地缓存&分别考虑架构问题。

问:这有用吗？使用时间戳参数作为缓存失效机制是有效的还是好的？

Answer 1

本地缓存更容易实现。值得注意的问题是：

1. 在缓存填充事件期间，多个缓存未命中。
2. 缓存填充失败。
3. 根据请求命中的服务器将返回不同的答案。

使用.NET，我通过让缓存存储Task<>异步包装器来处理缓存丢失问题，并使用锁定来确保只创建了一个获得缓存值的Task<>。这个效果很好。

当获取缓存值的进程失败时，应用程序会做什么？它是否缓存返回错误的失败，直到缓存过期？或者您是否创建了新的尝试来获得该值？

当您有一个具有独立缓存的多个服务器，并且基础值定期变化时，答案将完全取决于哪个服务器处理该请求。这可能不是您的应用程序中的一个问题，但是要仔细考虑这对您的用户意味着什么，以及他们对您的能力的信心。如果你不断得到相互矛盾的数据，它会破坏信任。

当您有多个应用服务器时，使用riak和key过期实现分布式缓存解决了许多这些问题。但是，当多个服务器上的多个线程都决定缓存需要重新填充时，它并不能解决缓存填充问题。