在前面的四篇文章中，我们从数据持久化层来聊了一些架构设计方案，来处理数据量大读写缓慢的问题。但是架构设计并不是只有这一方面的设计思路，本篇开始我们来从缓存层面来一起看看如何设计。

一、业务场景四

在一个电商系统中，存放了50000多条商品数据，每次用户浏览商品详情页时，需要先从数据库中读取数据，再进行数据拼装和计算，耗费的时间有时长达1秒。

这就导致每次点击商品详情页时，页面打开速度慢，此时该如何减少数据库读操作的压力呢？

在项目时间紧张，赶进度的时候，没更多的精力关注此类问题。但是当系统流量起来之后，这种问题就不能不考虑了。

此时采取的方案也比较通用，把所有的商品数据缓存起来就行。

关于缓存的问题，最简单的实现方法是使用本地缓存。在Google Guava中有一个cache内存缓存模块，它把所有商品的ID与商品详细信息一对一缓存至JVM内存中，用户获取商品详情数据时，系统会自动根据商品ID直接从缓存中读取数据，大大提升了用户页面访问速度。

不过，通过简单换算后，我们发现这个方法明显不合理，先来举个例子：

1条商品数据中，往往包含品牌、分类、参数、规格、服务、描述等字段，光存储这些商品数据就得占用500K左右内存，再将这些数据缓存到本地的话，差不多还需要占用500K*50000=25G内存。此时，假设商品服务有30个服务器节点，光缓存商品数据就需要额外准备750G内存空间，这种方法显然不可取。

为此，我们想到了另外一个解å决办法——分布式存储，先将所有缓存数据集中存储在同一个地方，而并非保存到各个服务器节点中，然后所有的服务器节点从这个地方读取数据。

那么这个统一存储缓存的地方需要使用什么技术呢？这就涉及接下来我们要聊的缓存中间件的技术选型问题。

二、缓存中间件技术选型

我们先将市面上比较流行的缓存中间件（Memcached、MongoDB、Redis）进行简单对比，这样大家就不用深入进行选型调研了。

据我了解，以上三种技术中，目前市面上通用的缓存中间件技术是Redis，使用MongoDB的公司最少，因为他只是一个数据库，由于他的读写速度与其他数据库相比较快，所以人们才把它当做类似缓存的存储。

在这里，我们总结一下Redis之所以比memcached流行的三种原因：

1、数据结构

举个例子，在使用 Memcached 保存 List 缓存对象的过程中，如果我们往 List 增加一条数据，首先需要读取整个 List ，再反序列化塞入数据，接着再序列化存储回 Memcached。而对于 Redis 而言，它仅仅是一个 Redis 请求，会直接帮我们塞入数据并存储，简单快捷。

2、持久化

对于 Memcached 来说，一旦系统宕机数据就会丢失。通过 Memcached 的官方文档得知，1.5.18 以后 Memcached 支持 restartable cache，其实现原理是重启时 CLI 先发信号给守护进程，然后守护进程将内存持久化至一个文件中，系统重启时再从那个文件恢复数据。不过，这个设计仅在正常重启情况下使用，意外情况还是不处理。

3、集群（这点尤为重要）

Memcached 的集群设计非常简单，客户端根据 Hash 值直接判断存取的 Memcached 节点。而 Redis 的集群因在高可用、主从、冗余、failover 等方面都有所考虑，所以集群设计相对复杂些，属于较常规的分布式高可用架构。

因此，经过一番“慎重”的思考，我们最终决定使用Redis作为缓存的中间件。

技术选型完，我们开始考虑缓存的一些具体问题，先从缓存何时存储数据入手。

三、缓存何时存储数据

使用缓存的逻辑是这样的：

1、先尝试从缓存中读取数据；

2、缓存中没有数据或者数据过期，再从数据库中读取数据保存到缓存中；

3、最终把缓存数据返回给调用方。

这种逻辑唯一麻烦的地方：当用户发来大量并发请求，且所有请求同时挤在上面第2步，此时如果这些请求全部从数据库读取数据，会直接挤爆数据库。

上面所说的挤爆可以分为三种情况，我们单独展开说一下：

1、单一数据过期或者不存在，这种情况称为缓存击穿。

此时解决方案：第一个线程如果发现key不存在，先给key加锁，再从数据库读取数据保存到缓存中，最后释放锁。如果其他线程正在读取同一个key值，它必须等到锁释放后才行。（关于锁的问题在第一篇文章中已经聊过了，就不再说了）

2、数据大面积过期或者Redis宕机，这种情况称之为缓存雪崩。

此时，我们设置缓存缓存过期时间随机分布或永不过期即可。

3、一个恶意请求获取的key不在数据库中，这种情况称之为缓存穿透。

这种情况如果不做处理，恶意请求每次都会查询数据库，无疑给数据库增加了压力。

这里分享2种解决办法：①在业务逻辑上直接校验，在数据库不被访问的前提下过滤掉不存在的key；②将恶意请求的key存放一个空值在缓存中，防止恶意请求骚扰数据库。

最后，说明一下关于缓存预热：在深夜无人或访问量小的时候，我们可以考虑将预热的热数据保存到缓存中，这样流量大的时候，用户查询无须再从数据库读取数据，大大减少了数据读压力。

关于缓存何时存数据的问题我们就讨论完了，接下来开始讨论更新缓存的问题，这部分内容涉及双写（缓存+数据库）。

四、如何更新缓存

更新缓存的步骤特别简单，总共就两步：更新数据库和更新缓存。但就这么简单的两步，我们需要考虑好几个问题。

1、先更新数据库还是先更新缓存？更新缓存时先删除还是直接更新？

2、假设第一步成功了，第二步失败了怎么办？

3、假设2个线程同时更新一个数据，A线程先完成第一步，B线程先完成第二步，此时该怎么办？

其中，第一个问题就存在4种组合问题，我们先针对第 1 种组合问题给出对应的解决方案。（以上几个问题因为紧密关联，没法单独考虑，下面我们就一起说明。）

组合一：先更新缓存，再更新数据库

对于这个组合，会遇到这种情况：假设第 2 步数据库更新失败了，要求回滚缓存的更新，这时该怎么办呢？我们知道 Redis 不支持事务回滚，除非我们采用手工回滚的方式，先保存原有数据，然后再将缓存更新回原来的数据，这种解决方案就有点尴尬了。

这里简单举个例子，比如：

1、原来缓存中的值是 a，两个线程同时更新库存；

2、线程 A 将缓存中的值更新成 b，且保存了原来的值 a，然后更新数据库；

3、线程 B 将缓存中的值更新成 c，且保存了原来的值 b，然后更新数据库；

4、线程 A 更新数据库时失败了，它必须回滚了，那现在缓存中的值更新回什么呢？

要不这样吧，我们在A线程更新缓存与数据库整个过程中，先把缓存及数据库都锁上，确保别人不能更新，这样的方法可不可行呢？当然是可行的，但是别人能不能读呢？

假设A更新数据库失败回滚缓存时，线程C也来参一腿，它需要先读取缓存中的值，这时又返回什么值呢？

看到这个场景，你是不是有点印象了？不错，这就是典型的事务隔离级别场景。我们只是使用一下缓存而已，你让我自己实现事务隔离级别，这个要求会不会有点高？我们还是考虑别的吧。

组合二：先删除缓存，再更新数据库

使用这种方案，就算我们更新数据库失败了也不需要回滚缓存。这种做法虽然巧妙规避了失败回滚的问题，却引来了两个更大的问题。

1、假设A线程先删除缓存，再更新数据库。在A线程完成更新数据库库之前，后执行的B线程反而超前完成了操作，读取key发现没数据后，将数据库中的旧值放到了缓存中。A线程在B线程都完成后再更新数据库，这样就会出现缓存（旧值）与数据库的值（新值）不一致的问题。

2、为了解决一致性的问题，我们可以让A线程给key加锁，因为写操作特别耗时，这种处理方法会导致大量的读请求卡在锁中。

以上描述的典型的高可用和一致性难以两全的问题，要再加上分区容错就是CAP了，这里我们就不展开讨论了。

组合三：先更新数据库，再更新缓存

对于组合三，我们同样需要考虑两个问题。

1、假设第一步成功，第二步失败了怎么办？因为缓存不是主流程，数据库才是，所以我们不会因为更新缓存失败而回滚第一步对数据库的更新。此时，我们一般采用的做法是做重试机制，但重试机制如果存在延时还是会出现数据库与缓存不一致的情况，非常不好处理啊。

2、假设2个线程同时更新同一个数据，A线程先完成了第一步，B线程先完成了第二步怎么办？

假设2个线程同时更新同一个数据，A线程先完成了第一步，B线程先完成了第二步怎么办？我们接着来推演整个过程：A线程把值更新a，B线程把值更新成b，此时数据库中的最新值是b，因为A线程先完成了第一步，后完成第二步，所以缓存中的最新值是a，数据库与缓存的值还是不一致，还是不好处理啊。

因此，我们不建议采用以上这个方案。

组合四：先更新数据库，再删除缓存

针对组合四，我们看看到底会存在哪些问题。

1、假设第一步成功了，第二步失败了怎么办？这种情况的出现概率与上个组合相比明显少不少，因为删除比更新容易多了。此时虽然它不完美，但出现一致性的问题概率少。

2、假设2个线程同时更新同一个数据，A线程先完成第一步，B线程先完成第二步怎么办？

这里我们接着推演整个过程：A线程把值更新成a，B线程把值更新成b，此时数据库中的最新值是b，因为A线程先完成了第一步，至于第二步谁先完成已经无所谓了，反正是直接删除缓存数据。

看到这里，我们发现组合四完美解决了以上难题，所以建议更新缓存时，先更新数据库再删除缓存。

不过，这个解决方案也会引发另外3个问题。

• 删除缓存数据后变相出现缓存击穿，此时该怎么办？此问题在前面我们已经给出了方案。
• 删除缓存失败如何重试？可以参考之前的查询分离使用重试的方案解决。
• 删除缓存失败，重试成功前出现脏数据。这个需要与业务商量，毕竟这种情况还是少见，我们可以根据实际业务情况判断是否需要解决这个瑕疵。毕竟任何一个方案都不是完美的，但如果剩下1%的问题需要我们花好几倍的代价去解决，从技术上来讲得不偿失，这就要求架构师协同PM去说服业务方。

前面我们花了大篇幅讨论更新缓存的逻辑，接下来我们来讨论缓存的高可用设计。

五、缓存的高可用设计

关于缓存高可用设计问题，在设计高可用方案时，我们需要考虑5个要点：

1、负载均衡：是否可以通过加节点的方式水平分担读请求压力。

2、分片：是否可以通过划分到不同的节点的方式水平分担写压力。

3、数据冗余：一个节点的数据如果挂掉了，其他节点是否可以直接备份挂掉节点的职责。

4、Fail-over：任何节点挂掉后，集群的职责是否可以重新分配，以此保障集群正常工作。

5、一致性保证：在数据冗余、failover、分片机制的数据转移过程中，如果某个地方出幺蛾子，能否保证所有的节点数据或节点与数据库之间数据的一致性。（依靠redis本身是不行的）

如果对缓存高可用有需求我们可以用使用Redis的cluster模式，关于前面提到的点它都有涉及。至于cluster怎么配置，可以参考Redis官方文档或网上教程，这里就不展开了。

1、缓存的监控

缓存上线后，我们还需要定时查看缓存的使用情况，再判断业务逻辑是否需要优化，也是就是所谓的缓存的监控。

在查看缓存使用情况时，一般我们会监控缓存命中率、内存使用率、慢日志、延迟、客户端连接数等数据。当然，随着问题的深入我们还需要增加其他指标，这里就不详细说了。

至于最终使用哪种监控工具，需要根据实际情况而定。这里推荐几款开源监控工具，比如RedisLive、Redis-monitor等。

六、此方案的价值和不足

以上方案可以顺利解决读数据请求压垮数据库的问题，目前互联网架构也基本是采取这里方案。但是这个方案还存在一个不足，无法解决写数据请求量大的问题，也就是说写请求多时，数据库还是会扛不住。针对这个问题，后面的文章中我们接着讨论。