是否有标准方法来计算不同类型缓存的 TTL？这更像是一个通用问题，因此假设我们正在从头开始设计一个系统，并且我们有以下要求/规范：
CDN 提供的静态资源很少更新，例如（隐私 政策、关于、图像和地图）
应用程序缓存用于 服务 a- 会话 b- 最近使用的读取，无论类型如何
客户端缓存（以前请求的文件），以及让我们说 客户可以看到的图像或帖子（类似于 Instagram/twitter 在这种情况下）
根据上面提供的很少或没有信息计算以下类型的 TTL：
【问题讨论】：
标签： caching redis architecture cdn
TTL 主要使用历史数据、用例和经验来定义。没有预定义的规则/理论可以告诉您缓存到期。缓存 TTL 应该有一些容忍度，例如如果您将 TTL 设置得太高，那么您可能会看到过期（陈旧）数据，陈旧数据对您的应用程序有什么影响？在某些情况下，完全不接受陈旧数据，但在其他情况下，可以在 SOME TIME 内使用陈旧数据。
不过，您会发现每个缓存系统都有一些预定义的 TTL，例如 AWS CDN 有 24 小时到期，Google CDN 有 1 小时。 Etag 是另一回事，用于 CDN。
CDN 可以捕获一周的数据，但根据数据，一些数据也可能每小时更改一次，因此在这种情况下，到期设置为较低的值，类似的事情适用于其他用例。
会话应该被缓存一周左右，但一些应用程序缓存会话更长的时间。当然，使用低/高 TTL 有利有弊。
应用数据缓存具有与CDN数据相似的特性，数据可以随时变化，变化必须反映在缓存中。再次根据应使用 TTL 的用例，我的经验是，您可以将某些数据缓存 1 天或 1 周，但某些数据的缓存时间不能超过 15 分钟，因为它可能会在 15 分钟内更新。
根据数据的性质，您总能找到一些最佳 TTL，找到最佳 TTL 需要时间，因为您必须监控缓存命中/未命中和过时数据比率。
参考
【讨论】：