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

一、业务场景四

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

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

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

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

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

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

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

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

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

二、缓存中间件技术选型

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

MemcachedMongoDBRedis 数据结构简单 key-value 非常全面，文档型数据库 String、List、Set、Hash、Bitmap 等持久化不支持支持支持集群客户端自己控制支持支持性能强中等强

据我了解，以上三种技术中，目前市面上通用的缓存中间件技术是 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 等。

六、此方案的价值和不足

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