缓存不像培根 控制你自己

biplobkumar5008

意这是 Brad Culberson 的三篇工程博客文章中的第一篇他是我们在 SendGrid 的最高级别工程师之一。如果您有兴趣阅读更多此类文章，请查看我们的技术博客。 大多数开发人员认为缓存就像培根。你可以把它加到任何东西上，这样会更好。我在生产环境中遇到过经常过于复杂并且实际上由于缓存而性能更差的代码。本文将指导您寻找什么以及应该如何评估您的缓存是否对您的应用程序有害。 数学 使用缓存的最佳情况是您完成任务的处理时间很长并且该任务很常见。在此示例中，我假设您从 Solr 获取数据的平均请求时间为 2 秒。查询的数量有限，因此当我们将查询结果添加到缓存时，每 100 个查询请求中有 80 个可用。

在这种情况下它的缓存命中率为缓存未命中率为。在这种情况下，每次从缓存中读取和写入都需要 2ms。 平均请求时间 缓存前时间：2000ms 使用缓存有很多不好的情况。我最近分析的一个是缓存从 Riak 中提取的数据。在这种 消费者手机号码数据库 情况下，Riak 的平均读取时间为 3 毫秒。到位的 Redis 缓存的平均读写时间为 2 毫秒。在这种情况下，缓存命中率为 60%，这听起来不错，对吧？ 平均请求时间：缓存前时间：3ms 在这种情况下，我们通过增加 Redis 缓存的复杂性来增加 毫秒的延迟。为简单起见，这些时序还排除了使缓存无效所需的任何工作但这将更加不利缓存解决方案。



经过分析我们去掉了缓存大幅简化了代码。 我经常遇到的另一个坏情况是关系数据库的缓存，它按键缓存。关系数据库在将热点项目保存在内存中做得非常出色，并且在按键查询方面表现出色。以我的经验，仅仅因为缓存和数据库的速度差异可以忽略不计，数学很少适用于在另一个系统中进行缓存。您不会获得 100% 的命中率，并且您还将使用缓存更新和逐出时间来惩罚更新和删除。如果您想查看 MySQL 上缓存的最小节省量（微秒），我发布了一个基准测试“节省量”的代码库。 不要让您的应用沉迷于培根 在完成计算并确定缓存有效之后您的工作还没有完成。