缓存——不可避免的罪恶
缓存——不可避免的罪恶
原文：https://medium.com/hackernoon/caching-necessary-evil-b5511140b26d
在设计低延迟、高吞吐量的系统时，缓存起着重要的作用。当您希望处理请求时，您希望尽可能避免 I/O 操作。原因是这样做需要时间—磁盘寻道成本高，网络呼叫成本高。典型时间(来源)
通过 1 Gbps 网络发送 2K 字节— 20，000 纳秒
从内存中顺序读取 1MB—250，000 ns
从磁盘顺序读取 1MB—20，000，000 ns
在缓存时，应该始终牢记数据的规模。我思考缓存的过程如下。
你真的需要缓存吗？
缓存会导致不一致，应该尽可能避免。检查系统是否满足非功能性要求(NFR)、延迟和吞吐量，无需缓存。如果这样做，不要在系统中添加缓存。如果没有，检查需求是否正确，是否真的需要严格的 nfr。例如:
(a)如果有人说您需要在 10 毫秒内获取 30 个项目的数据，这可能不现实。如果等待时间为 100 毫秒，这可能是合理的。
(b)许多时候，对不同系统的调用是并行进行的。考虑一个调用服务 A 和 B 的系统，然后计算合并结果的输出。如果有人说延迟应该是 100 毫秒，而 B 应该是 200 毫秒。你的系统在没有缓存的情况下可以工作 150 毫秒。你应该尝试在 100 毫秒的数字背后进行推理(你应该总是质疑来自魔法帽的数字)。如果没有推理，应该改成 200 ms，不做缓存。
数据大小和使用模式
一种安全的缓存方法是使用中央缓存存储。它确保您的所有应用程序实例读取相同的值(为了简单起见，让我们忽略缓存存储中的复制延迟)。更新值也很容易，因为您只需要在中央缓存中进行更新。但是根据我们需要缓存的数据和大小，我们可以采用几种不同的方法。
(a)几 MBs 的不可变数据或缓慢变化的数据
对于这种情况，可以考虑在应用程序内存中进行缓存。在运行时使用预加载，或者在第一次读取时使用惰性加载。对于不可变数据，不需要传播写操作。此外，它还减少了一个需要维护的组件。为了更新，实体可以在一段时间后到期，以便可以加载新数据。例如:假设您想要缓存某个国家/地区的名称或 pin。或参加特定比赛的运动员名单。
(b)数百兆字节的不可变或缓慢变化的数据
对于变化缓慢的数据，您不应该将数据保存在内存中，而应该将其移动到数据存储中。但是，您可以将数据保存在与服务相同的盒子中，即，将应用程序和缓存数据存储放在同一台机器中。它减少了网络延迟，但代价是陈旧数据和写入复杂性的增加(因为您必须写入所有机器的缓存)。但是，如果您在处理请求时需要获取大量数据，这可能是值得探索的。将写入传播到缓存的一个策略可以是在主存储上设置侦听器，它更新所有应用程序计算机上的缓存。只有当中央缓存存储不符合我的要求时，我才会选择它。
另一个代价是，无论何时添加新实例，缓存都需要预热。因此，新机器高效运行可能需要时间。
(c)单位为 GBs
你应该选择中央缓存。否则，它可能会限制您可以使用的机器类型。如果你使用云服务，你可能需要更贵的机器。缓存预热时间也会增加。更大的数据意味着更多的实体。即使单个的变化率更大，累积的变化率也可能很大。
(d)不同数据中心的数据
在这种情况下，每个数据中心一个缓存数据存储可能是有用的。如果仅在一个数据中心，网络延迟会很大，可能会抵消缓存的优势(因为从主数据存储读取的时间可能会少于网络延迟)。
驱逐政策
对于缓存，你通常必须考虑驱逐策略。如果空间不足，应该使用基于大小的策略来清除缓存。如果数据在一定时间后变得陈旧，请使用基于时间的策略。如果你有足够的内存并且数据不会过时，你可以不驱逐数据。
一般来说，LRU 和 LFU 的策略是选择需要删除的条目。
战争故事
(a)每天晚上 7 点的 DB 负载
每天晚上 7 点，db 的负载增加。这是因为使用了基于时间的缓存策略。同时也是网站流量最高的时候。将缓存重新加载时间移到网站流量较少的清晨解决了这个问题。
学习:如果你使用基于时间的驱逐。确保你在网站流量少的时候做
(b)用户无法更新个人资料
我听说的一个例子是人们缓存了个人资料页面显示的用户数据。当人们更新他们的信息，并再次进入个人资料页面，他们看到相同的数据。他们又试了一次，结果还是一样。虽然它在数据库中更新，由于缓存用户数据无法看到更新的结果。
学习:你应该小心更新和你应该在哪里缓存数据
页（page 的缩写）这是我随着时间的推移学到的东西的杂凑。如果我漏掉了什么参考文献，一定要告诉我，我会补充的
黑客中午是黑客如何开始他们的下午。我们是 @AMI 家庭的一员。我们现在接受投稿，并乐意讨论广告&赞助机会。
要了解更多信息，请阅读我们的“关于”页面、在脸书上点赞/给我们发消息，或者简单地说， tweet/DM @HackerNoon。