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

在这里插入图片描述

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

一、业务场景四

在一个电商系统中,存放了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等。

六、此方案的价值和不足

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

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

我爱娃哈哈

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值