4.6　服务端缓存

笔者介绍透明多级分流系统的逻辑思路是以流量从客户端中发出为起始，以流量到达服务器集群中真正处理业务的节点为终结，探索该过程中与业务无关的通用组件。事实上很难清楚界定服务端缓存到底算不算与业务逻辑无关，不过，既然本章以“客户端缓存”为开篇，那“服务端缓存”作为结束，倒是十分合适的。注意，在这一节里，笔者所说的“缓存”，均特指服务端缓存。

为系统引入缓存之前，第一件事情是确认系统是否真的需要缓存。很多人会有意无意地把硬件中常用于区分不同产品档次、“多多益善”的缓存（如CPU L1/2/3缓存、磁盘缓存，等等）代入软件开发中去，实际上这两者差别很大，在软件开发中引入缓存的负面作用要明显大于硬件缓存带来的负面作用：从开发角度来说，引入缓存会提高系统复杂度，因为你要考虑缓存的失效、更新、一致性等问题（硬件缓存也有这些问题，只是不需要由你去考虑，主流的ISA也都没有提供任何直接操作缓存的指令）；从运维角度来说，缓存会掩盖一些缺陷，让问题在更久的时间以后，出现在距离发生现场更远的位置上；从安全角度来说，缓存可能会泄漏某些保密数据，也是容易受到攻击的薄弱点。冒着上述种种风险，仍能说服你引入缓存的理由，总结起来无外乎以下两种。

·为缓解CPU压力而引入缓存：譬如把方法运行结果存储起来、把原本要实时计算的内容提前算好、对一些公用的数据进行复用，这可以节省CPU算力，顺带提升响应性能。

·为缓解I/O压力而引入缓存：譬如把原本对网络、磁盘等较慢介质的读写访问变为对内存等较快介质的访问，将原本对单点部件（如数据库）的读写访问变为对可扩缩部件（如缓存中间件）的访问，顺带提升响应性能。

请注意，缓存虽然是典型以空间换时间来提升性能的手段，但它的出发点是缓解CPU和I/O资源在峰值流量下的压力，“顺带”而非“专门”地提升响应性能。这里的言外之意是如果可以通过增强CPU、I/O本身的性能（譬如扩展服务器的数量）来满足需要的话，那升级硬件往往是更好的解决方案，即使需要一些额外的投入成本，也通常要优于引入缓存后可能带来的风险。