数据量大读写缓慢如何优化（5）【读缓存】

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

1、业务场景四

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

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

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

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

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

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

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

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

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

2、缓存中间件技术选型

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

	Memcached	MongoDB	Redis
数据结构	简单key-value	很是全面，文档型数据库	String、List、Set、Hash、Bitmap等
持久化	不支持	支持	支持
集群	客户端本身控制	支持	支持
性能	强	中等	强

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

在这里，咱们总结一下Redis之因此比memcached流行的三种缘由：

一、数据结构

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

二、持久化

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

三、集群（这点尤其重要）

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

所以，通过一番“慎重”的思考，咱们最终决定使用Redis做为缓存的中间件。

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

3、缓存什么时候存储数据

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

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

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

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

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

上面所说的挤爆能够分为三种状况，咱们单独展开说一下：

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

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

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

此时，咱们设置缓存缓存过时时间随机分布或永不过时便可。

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

这种状况若是不作处理，恶意请求每次都会查询数据库，无疑给数据库增长了压力。

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

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

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

4、如何更新缓存

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、为了解决一致性的问题，咱们可让A线程给key加锁，由于写操做特别耗时，这种处理方法会致使大量的读请求卡在锁中。

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

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

对于组合三，咱们一样须要考虑两个问题。

一、假设第一步成功，第二步失败了怎么办？由于缓存不是主流程，数据库才是，因此咱们不会由于更新缓存失败而回滚第一步对数据库的更新。此时，咱们通常采用的作法是作重试机制，但重试机制若是存在延时仍是会出现数据库与缓存不一致的状况，很是很差处理啊。

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

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

所以，咱们不建议采用以上这个方案。

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

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

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

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

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

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

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

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

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

5、缓存的高可用设计

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

一、负载均衡：是否能够经过加节点的方式水平分担读请求压力。

二、分片：是否能够经过划分到不一样的节点的方式水平分担写压力。

三、数据冗余：一个节点的数据若是挂掉了，其余节点是否能够直接备份挂掉节点的职责。

四、Fail-over：任何节点挂掉后，集群的职责是否能够从新分配，以此保障集群正常工做。

五、一致性保证：在数据冗余、failover、分片机制的数据转移过程当中，若是某个地方出幺蛾子，可否保证全部的节点数据或节点与数据库之间数据的一致性。（依靠redis自己是不行的）

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

一、缓存的监控

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

在查看缓存使用状况时，通常咱们会监控缓存命中率、内存使用率、慢日志、延迟、客户端链接数等数据。固然，随着问题的深刻咱们还须要增长其余指标，这里就不详细说了。

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

6、此方案的价值和不足

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