缓存能解决的问题
提升性能
绝大多数情况下，select 是出现性能问题最大的地方。一方面，select 会有很多像 join、group、order、like 等这样丰富的语义，而这些语义是非常耗性能的；另一方面，大多 数应用都是读多写少，所以加剧了慢查询的问题。
分布式系统中远程调用也会耗很多性能，因为有网络开销，会导致整体的响应时间下降。为了挽救这样的性能开销，在业务允许的情况（不需要太实时的数据）下，使用缓存是非常必要的事情。
缓解数据库压力
当用户请求增多时，数据库的压力将大大增加，通过缓存能够大大降低数据库的压力。
缓存使用场景
对于数据实时性要求不高
对于一些经常访问但是很少改变的数据，读明显多于写，适用缓存就很有必要。比如一些网站配置项。
缓存三种模式
Cache Aside 【同时更新缓存和数据库】
Read/Write Through 【先更新缓存，缓存负责同步更新数据库】
Write Behind Caching 【先更新缓存，缓存定时异步更新数据库】
Cache Aside
失效：应用程序先从 cache 取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
命中：应用程序从 cache 中取数据，取到后返回。
更新：先把数据存到数据库中，成功后，再让缓存失效。
缓存更新时先更新数据库，然后在让缓存失效。那么为什么不是直接更新缓存呢？
先更新数据库，再更新缓存。这种做法最大的问题就是两个并发的写加粗样式操作导致脏数据。两个并发更新操作，数据库先更新的反而后更新缓存，数据库后更新的反而先更新缓存。这样就会造成数据库和缓存中的数据不一致，应用程序中读取的都是脏数据。
先删除缓存，再更新数据库。这个逻辑是错误的，因为两个并发的读和写操作导致脏数据。假设更新操作先删除了缓存，此时正好有一个并发的读操作，没有命中缓存后从数据库中取出老数据并且更新回缓存，这个时候更新操作也完成了数据库更新。此时，数据库和缓存中的数据不一致，应用程序中读取的都是原来的数据（脏数据）。
先更新数据库，再删除缓存。这种做法其实不能算是坑，在实际的系统中也推荐使用这种方式。但是这种方式理论上还是可能存在问题。查询操作没有命中缓存，然后查询出数据库的老数据。此时有一个并发的更新操作，更新操作在读操作之后更新了数据库中的数据并且删除了缓存中的数据。然而读操作将从数据库中读取出的老数据更新回了缓存。这样就会造成数据库和缓存中的数据不一致，应用程序中读取的都是原来的数据（脏数据）。
但是，仔细想一想，这种并发的概率极低。因为这个条件需要发生在读缓存时缓存失效，而且有一个并发的写操作。实际上数据库的写操作会比读操作慢得多，而且还要加锁，而读操作必需在写操作前进入数据库操作，又要晚于写操作更新缓存，所有这些条件都具备的概率并不大。但是为了避免这种极端情况造成脏数据所产生的影响，我们还是要为缓存设置过期时间。
1、先更新数据库，再更新缓存 update与commit之间，更新缓存，commit失败 则DB与缓存数据不一致。
• 2、先删除缓存，再更新数据库 update与commit之间，有新的读，缓存空，读DB数据到缓存 数据是旧的数据 commit后 DB为新数据 则DB与缓存数据不一致
• 3、先更新数据库，再删除缓存（推荐） update与commit之间，有新的读，缓存空，读DB数据到缓存 数据是旧的数据 commit后 DB为新数据 则DB与缓存数据不一致 解决方法：采用延时双删策略
读操作
客户端先读 cache，如果 cache 没有，则读 DB ，同时将从 DB中读取的数据回写到 cache。
写操作
由客户端先更新 DB ，然后直接将 key 从 Cache 中删除，由 DB 来驱动缓存数据的更新。
特点
这种模式的特点是，业务端处理所有数据访问细节，同时利用 Lazy 计算的思想，更新 DB 后，直接删除 Cache 并通过 DB 更新，确保数据以 DB 结果为准，可以大幅降低 Cache 和 DB 中数据不一致的概率。
对于 Cache Aside 模式，业务应用需要同时维护 cache 和 DB 两个数据存储方，过于繁琐，于是就有了 Read/Write Through 模式。在这种模式下，业务应用只关注一个存储服务即可，业务方的读写 cache 和 DB 的操作，都由存储服务代理。
Read/Write Through
在上面的 Cache Aside 更新模式中，应用代码需要维护两个数据存储，一个是缓存（Cache），一个是数据库（Repository）。而在Read/Write Through 更新模式中，应用程序只需要维护缓存，数据库的维护工作由缓存代理了。
Read Through
Read Through 模式就是在查询操作中更新缓存，也就是说，当缓存失效的时候，Cache Aside 模式是由调用方负责把数据加载入缓存，而 Read Through 则用缓存服务自己来加载。
读操作 跟Cache Aside 一样。
写操作
存储服务首先查 Cache，如果数据在 Cache 中不存在，则只更新 DB；如果数据在 Cache 中存在，则先更新 Cache，然后更新 DB。
进行写操作时，如果 cache 中没有数据则不更新，有缓存数据才更新，内存效率更高。
Write Through
Write Through 模式和 Read Through 相仿，不过是在更新数据时发生。当有数据更新的时候，
如果没有命中缓存，直接更新数据库，然后返回。
如果命中了缓存，则更新缓存，然后由缓存自己更新数据库（这是一个同步操作）。
Write Behind Caching
Write Behind Caching 更新模式就是在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是直接操作内存速度快。因为异步，Write Behind Caching 更新模式还可以合并对同一个数据的多次操作到数据库，所以性能的提高是相当可观的。
但其带来的问题是，数据不是强一致性的，而且可能会丢失。另外，Write Behind Caching 更新模式实现逻辑比较复杂，因为它需要确认有哪些数据是被更新了的，哪些数据需要刷到持久层上。只有在缓存需要失效的时候，才会把它真正持久起来。
三种缓存模式的优缺点：
Cache Aside 更新模式实现起来比较简单，但是需要维护两个数据存储，一个是缓存（Cache），一个是数据库（Repository）。
Read/Write Through 更新模式只需要维护一个数据存储（缓存），但是实现起来要复杂一些。
Write Behind Caching 更新模式和Read/Write Through 更新模式类似，区别是Write Behind Caching 更新模式的数据持久化操作是异步的，但是Read/Write Through 更新模式的数据持久化操作是同步的。优点是直接操作内存速度快，多次操作可以合并持久化到数据库。缺点是数据可能会丢失，例如系统断电等。
缓存是通过牺牲强一致性来提高性能的。所以使用缓存提升性能，就是会有数据更新的延迟。这需要我们在设计时结合业务仔细思考是否适合用缓存。然后缓存一定要设置过期时间，这个时间太短太长都不好，太短的话请求可能会比较多的落到数据库上，这也意味着失去了缓存的优势。太长的话缓存中的脏数据会使系统长时间处于一个延迟的状态，而且系统中长时间没有人访问的数据一直存在内存中不过期，浪费内存。
