【发布时间】：2010-09-18 17:44:04
【问题描述】：
好的，我知道我之前问过这个问题，答案基本上是不经常更改的缓存数据。
那么当至少 99.9% 的数据发生变化时该怎么办？
在我的项目中，唯一不会更新或不会经常更新的表是成员个人资料信息（姓名/地址和设置）
那么，如何在仍然启用某种缓存的同时保持并确保正在查看的数据在应用更改时得到更新？
【问题讨论】：
【发布时间】：2010-09-18 17:44:04
【问题描述】：
我猜，并不是 99.9% 的数据发生了变化，而是 99.9% 的数据位置发生了变化。
例如，如果您正在运行公告板，则意味着会有源源不断的新帖子，但旧帖子将保持不变，甚至旧帖子也会保持很长时间不变。
在这种情况下，您需要一种使旧缓存数据无效的方法，以便您可以在查看线程（在示例中）后立即构建缓存。如果其中一个线程发生更改（即当有人添加新帖子时），则该缓存项目将被删除/标记为过时，因此下次查看时，它将被重建。不过，其他尚未更改的项目将使用缓存。
【讨论】：
如果您的数据在每次查看时都发生变化，那么缓存的意义就落空了 - 您应该寻找其他类型的优化。
如果它每隔一段时间就改变一次，那么它可能仍然不值得缓存 - 不要忘记将某些内容存储到缓存中会产生一些开销
【讨论】：
真正相关的考虑因素是这 99.9% 的信息多久更改一次，是每次访问、每秒、每分钟、每小时吗？任何高于访问权限的内容，取决于您拥有的每个时间单位的请求数量和您选择的缓存方案，都可能有意义。
只要平均检索时间减少，缓存。 您必须对此进行衡量并做出决定。
一些缓存验证技术是在访问时检查有效性或将时间戳和到期时间与缓存一起存储。每次访问时检查有效性的成本更高，并且时间戳+过期在某些情况下可能会提供陈旧的内容。
【讨论】：
视情况而定。
如果您愿意做出这种牺牲（即，事情变得非常糟糕，性能方面），您可能需要考虑以小间隔（10 秒、30 秒、1 分钟...）缓存数据以减少数据库的负载。数据不会是最新的，但可能足够新鲜。
如果几乎没有任何负载，则无需开始摆弄缓存。真的，没有必要去寻找不存在的问题。毕竟 - 许多数据库引擎都有自己的缓存，不仅用于数据，还用于执行计划。
【讨论】：
-
这非常适合缓存“随机”数据——比如在主页上随机显示热门新闻或随机广告。如果你有例如100 个请求/秒，将此信息缓存 1-5 秒是非常好的和安全的，因此同一秒内的每个访问者都会获得相同的“随机”帖子/广告。
在单实例 Web 应用程序场景中，您可以在对象更改时手动更新缓存，也可以在数据库中更新。
有时您可以刷新缓存以确保没有不同步的情况（例如，如果数据库被其他应用程序更新）。
请注意，这不适用于企业级场景。
【讨论】：