零、 题记

在高并发场景下，需要通过缓存来减少数据库的压力，使得大量的访问进来能够命中缓存，只有少量的需要到数据库层。由于缓存基于内存，可支持的并发量远远大于基于硬盘的数据库。所以对于高并发设计，缓存的设计是必不可少的一环。

一、为什么要使用缓存

为什么要使用缓存呢？源于人类的一个梦想，就是多快好省的建设社会主义。多快好省？很多客户都这么要求，但是作为具体做技术的你，当然知道，好就不能快，多就没法省。

可是没办法，客户都这样要求：
这个能不能便宜一点，你咋这么贵呀，你看人家都很便宜的。(您好，这种打折的房间比较靠里，是不能面向大海的)
你们的性能怎么这么差啊，用你这个系统跑的这么慢，你看人家广告中说速度能达到多少多少。(您好，你如果买一个顶配的，我们也是有这种性能的)
你们服务不行啊，你就不能彬彬有礼，穿着整齐，送点水果瓜子啥的？(您好，我们兰州拉面馆没有这项服务，可以去对面的俏江南看一下)
这么贵的菜，一盘就这么一点点，都吃不饱，就不能上一大盘么。（您好，对面的兰州拉面10块钱一大碗）
怎么办呢？劳动人民还是很有智慧的，就是聚焦核心需求，让最最核心的部分享用好和快，而非核心的部门就多和省就可以了。
你可以大部分时间住在公司旁边的出租屋里面，但是出去度假的一个星期，选一个面朝大海，春暖花开的五星级酒店。
你可以大部分时间都挤地铁，挤公交，跋涉2个小时从北五环到南五环，但是有急事的时候，你可以打车，想旅游的时候，可以租车。
你可以大部分时间都吃普通的餐馆，而朋友来了，就去高级饭店里面搓一顿。

在计算机世界也是这样样子的，如图所示。

越是快的设备，存储量越小，越贵，而越是慢的设备，存储量越大，越便宜。

对于一家电商来讲，我们既希望存储越来越多的数据，因为数据将来就是资产，就是财富，只有有了数据，我们才知道用户需要什么，同时又希望当我想访问这些数据的时候，能够快速的得到，双十一拼的就是速度和用户体验，要让用户有流畅的感觉。

所以我们要讲大量的数据都保存下来，放在便宜的存储里面，同时将经常访问的，放在贵的，小的存储里面，当然贵的快的往往比较资源有限，因而不能长时间被某些数据长期霸占，所以要大家轮着用，所以叫缓存，也就是暂时存着。

二、都有哪些类型的缓存

当一个应用刚开始的时候，架构比较简单，往往就是一个Tomcat，后面跟着一个数据库。

简单的应用，并发量不大的时候，当然没有问题。

然而数据库相当于我们应用的中军大帐，是我们整个架构中最最关键的一部分，也是最不能挂，也最不能会被攻破的一部分，因而所有对数据库的访问都需要一道屏障来进行保护，常用的就是缓存。
我们以Tomcat为分界线，之外我们称为接入层，接入层当然应该有缓存，还有CDN。
Tomcat之后，我们称为应用层，应用层也应该有缓存，这是我们这一节讨论的重点。
最简单的方式就是Tomcat里面有一层缓存，常称为本地缓存LocalCache。

这类的缓存常见的有Ehcache和Guava Cache，由于这类缓存在Tomcat本地，因而访问速度是非常快的。

但是本地缓存有个比较大的缺点，就是缓存是放在JVM里面的，会面临Full GC的问题，一旦出现了FullGC，就会对应用的性能和相应时间产生影响，当然也可以尝试jemalloc的分配方式。

还有一种方式，就是在Tomcat和Mysql中间加了一层Cache，我们常称为分布式缓存。

分布式缓存常见的有Memcached和Redis，两者各有优缺点。

Memcached适合做简单的key-value存储，内存使用率比较高，而且由于是多核处理，对于比较大的数据，性能较好。

但是缺点也比较明显，Memcached严格来讲没有集群机制，横向扩展完全靠客户端来实现。另外Memcached无法持久化，一旦挂了数据就都丢失了，如果想实现高可用，也是需要客户端进行双写才可以。

所以可以看出Memcached真的是设计出来，简简单单为了做一个缓存的。

Redis的数据结构就丰富的多了，单线程的处理所有的请求，对于比较大的数据，性能稍微差一点。

Redis提供持久化的功能，包括RDB的全量持久化，或者AOF的增量持久化，从而使得Redis挂了，数据是有机会恢复的。

Redis提供成熟的主备同步，故障切换的功能，从而保证了高可用性。

所以很多地方管Redis称为内存数据库，因为他的一些特性已经有了数据库的影子。

这也是很多人愿意用Redis的原因，集合了缓存和数据库的优势，但是往往会滥用这些优势，从而忽略了架构层面的设计，使得Redis集群有很大的风险。

很多情况下，会将Redis当做数据库使用，开启持久化和主备同步机制，以为就可以高枕无忧了。

然而Redis的持久化机制，全量持久化则往往需要额外较大的内存，而在高并发场景下，内存本来就很紧张，如果造成swap，就会影响性能。增量持久化也涉及到写磁盘和fsync，也是会拖慢处理的速度，在平时还好，如果高并发场景下，仍然会影响吞吐量。

所以在架构设计角度，缓存就是缓存，要意识到数据会随时丢失的，要意识到缓存的存着的目的是拦截到数据库的请求。如果为了保证缓存的数据不丢失，从而影响了缓存的吞吐量，甚至稳定性，让缓存响应不过来，甚至挂掉，所有的请求击穿到数据库，就是更加严重的事情了。

如果非常需要进行持久化，可以考虑使用levelDB此类的，对于随机写入性能较好的key-value持久化存储，这样只有部分的确需要持久化的数据，才进行持久化，而非无论什么数据，通通往Redis里面扔，同时统一开启了持久化。

三、基于缓存的架构设计要点

所以基于缓存的设计：

1、多层次
这样某一层的缓存挂了，还有另一层可以撑着，等待缓存的修复，例如分布式缓存因为某种原因挂了，因为持久化的原因，同步机制的原因，内存过大的原因等，修复需要一段时间，在这段时间内，至少本地缓存可以抗一阵，不至于一下子就击穿数据库。而且对于特别特别热的数据，热到导致集中式的缓存处理不过来，网卡也被打满的情况，由于本地缓存不需要远程调用，也是分布在应用层的，可以缓解这种问题。

2、分场景
到底要解决什么问题，可以选择不同的缓存。是要存储大的无格式的数据，还是要存储小的有格式的数据，还是要存储一定需要持久化的数据。具体的场景下一节详细谈。

3、要分片
使得每一个缓存实例都不大，但是实例数目比较多，这样一方面可以实现负载均衡，防止单个实例称为瓶颈或者热点，另一方面如果一个实例挂了，影响面会小很多，高可用性大大增强。分片的机制可以在客户端实现，可以使用中间件实现，也可以使用Redis的Cluster的方式，分片的算法往往都是哈希取模，或者一致性哈希。

四、缓存的使用场景

当你的应用扛不住，知道要使用缓存了，应该怎么做呢？

场景1：和数据库中的数据结构保持一致，原样缓存
这种场景是最常见的场景，也是很多架构使用缓存的适合，最先涉及到的场景。

基本就是数据库里面啥样，我缓存也啥样，数据库里面有商品信息，缓存里面也放商品信息，唯一不同的是，数据库里面是全量的商品信息，缓存里面是最热的商品信息。

每当应用要查询商品信息的时候，先查缓存，缓存没有就查数据库，查出来的结果放入缓存，从而下次就查到了。

这个是缓存最最经典的更新流程。这种方式简单，直观，很多缓存的库都默认支持这种方式。

 

场景2：列表排序分页场景的缓存

有时候我们需要获得