也谈如何构建高性能服务端程序

正文

请到「今天看啥」查看全文

Cache 就是为了来解决这个事情的，因为事情往往是这样的：你会发现一些非常复杂的过程的计算结果是可重用的，而且把这个结果暂时存储在某些地方，查找起来也是极为方便的。

所以，现在你理解了缓存，那可以来思考一些缓存的设计策略了。这里做一点说明，不同的缓存策略跟具体的业务系统关系非常大，制定缓存策略需要根据具体的情况来分析。常用的策略：

• 最终结果型缓存。这种缓存往往提升性能效果最为明显，但是命中率却低，也就是可重用性不高。

• 中间结果型缓存。还拿上面的例子来说，1加到100，你可以构建出是个缓存分别是1加到10，10加到20，20加到30 … 一直到 90加到100 这9个缓存。好处是你如果被请求到 1加到60 的时候，仍然可以使用这些缓存结果。可坏处也很明显，你取到几个缓存的结果后不得不再进行一次运算。所以实际情况，往往是在最终结果和中间结果之间找到平衡点，或者是两者配合使用。

不知不觉中，你有没有发现，1+2+3+4+…+99+100=5050 是个永远都成立的事实，这也就意味着，它永远不用被清除。可事实是往往是，缓存是有有效期的，例如需要缓存今天的天气情况，今天是 2014年11月16日，到了明天就是 11月17日，天气就不一样了。再例如需要缓存 Coding 的最新冒泡列表，当有人发布了新的冒泡，那么这个列表就得被更新。从这个角度来看，缓存的策略又有如下常见的几种：

• 永久式缓存：结果在任何情况下都不发生改变，无需清除或者更新

• 有有效期的缓存：在特定时间点或者时间段后失效

• 触发式失效缓存：当某一事件产生时，缓存失效，当然有有效期式缓存也可以理解成时间点和时间段到期为触发条件的触发式失效缓存

嗯，既然提到了缓存的更新或者清除，那么就牵扯到缓存的更新策略。例子永远好过大段的理论：假如我们要缓存 Coding 的冒泡列表。有这么一种策略：当用户请求时我们检查下是否已存在这样的缓存，如果有直接返回缓存数据，否则我们生成这个列表（计算机的计算过程），返回给用户并且把冒泡列表（计算结果）存储起来，以便以后的用户访问时直接获取。当用户发布了一个新的冒泡的时候，我们清除这个缓存，再有用户请求时将重复以上过程。这是其中一种完整的缓存清除策略。另外一种是，每当我们收到一个用户发布的冒泡时，都重新构建这个缓存，用户每次查看冒泡列表都是取的缓存数据。这两种缓存分别称之为：

请到「今天看啥」查看全文