一、缓存的成本和收益是什么

既然要讨论是否真的需要缓存这个问题，就要知道缓存带来的成本与收益（好处、坏处）是什么？

方案	收益	成本
缓存 + 后端存储(资源)	1. 加速读写 2. 降低后端负载	1. 数据不一致性 2. 代码维护成本 3. 架构复杂度

上面的表格应该清楚的表达了使用缓存后的收益和成本分别是什么。下面将进行详细的解析

二、缓存成本与收益详解

收益是很明显的，通常来说一个设计还不错的缓存系统，能够帮助你的业务实现加速读写，同时帮助降低了后端负载。

(1) 加速读写：通常来说加速是明显的，因为缓存通常都是全内存的系统，而后端（可能是mysql、甚至是别人的HTTP, RPC接口）都有速度慢和抗压能力差的特性，通过缓存的使用可以有效的提高用户的访问速度同时优化了用户的体验。

(2) 降低后端负载：通过缓存的添加，如果程序没有什么问题，在命中率还可以的情况下，可以帮助后端减少访问量和复杂计算(join、或者无法在优化的sql等)，在很大程度降低了后端的负载。
成本：

(1) 数据不一致性：无论你的设计做的多么好，缓存数据与权威数据源（可以理解成真实或者后端数据源）一定存在着一定时间窗口的数据不一致性，这个时间窗口的大小可大可小，具体多大还要看一下你的业务允许多大时间窗口的不一致性。

(2) 代码维护成本：加入缓存后，代码就会在原数据源基础上加入缓存的相关代码，例如原来只是一些sql, 现在要加入k-v缓存，必然增加了代码的维护成本。

(3) 架构复杂度：加入缓存后，例如加入了redis-cluster，一般来说缓存不会像Mysql有专门的DBA，很有可能没有专职的管理人员，所以也增加了架构的复杂度和维护成本。

如果当前系统的访问速度和访问量能够满足现有的要求，就不必增加缓存，其实像mysql并没有那么差，一台运行良好的Mysql，扛个QPS=1000没什么问题。

如果要加入选择了缓存，一定要能给出足够的理由，不是为了简单的show技术和想当然，最好的方法就是用数据说话：加速比有多少、后端负载降低了多少。

在公司里，据我观察，无论怎么更新架构，使用各种新技术，但是80%的项目还是离不开SQL的，下面我们以SQL作为后端数据源、以Redis作为缓存层，说一下哪些场景是需要缓存的。

复杂开销大的计算、降低后端负载

以Mysql为例子，一些复杂的操作或者计算(例如大量联表操作、一些分组计算)，如果不加缓存，大量流量将在这些复杂计算的执行。
加速请求响应

即使单条后端数据足够快（例如select * from table where id=?），那么依然可以利用redis/memcache将这些操作进行merge做优化(例如：cache(select * from table where id in(id1,id10….idK)))，从而优化整个IO链的相应时间。