26.【学习心得】学习心得-读缓存

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介: 【学习心得】学习心得-读缓存

文档参考:书名:《从程序员到架构师:大数据量、缓存、高并发、微服务、多团队协同等核心场景实战》-王伟杰

image.png

前文如下:


23.【学习心得】学习心得-冷热分离概述

24.【学习心得】学习心得-如何分离冷热数据

25.【学习心得】学习心得-基于MySQL的分表分库


1.业务场景:如何将十几秒的查询请求优化成毫秒级


每个电商系统都有个商品详情页。一开始这个页面很简单,只包括商品的图片、介绍、规格、评价等。刚开始,这个页面打开很快,系统运行平稳可靠。


后来,页面中加了商品推荐,即在商品详情页后面显示一些推荐商品的列表。


再后来,页面中加入了最近成交情况,即显示一下某人在什么时候下单了。接着,页面中又加入了优惠活动,即显示这个商品都可以参加哪些优惠活动。


……当时这个系统里面有5万多条商品数据,数据量并不大,但是每次用户浏览商品详情页时都需要几十条SQL语句,经常出现十几秒才能打开详情页的情况。这样的用户体验当然不好。


一个解决办法——分布式缓存,先将所有的缓存数据集中存储在同一个地方,而非重复保存到各个服务器节点中,然后所有的服务器节点都从这个地方读取数据。


那么这个统一存储缓存数据的地方需要使用什么技术呢?这就涉及接下来要讲的缓存中间件技术选型问题了。


2. 缓存中间件技术选型(Memcached,MongoDB,Redis)


先将目前比较流行的缓存中间件Memcached、MongoDB、Redis进行简单对比,见表4-1。

网络异常,图片无法展示
|


比较Redis和Memcached,并从中做出选择。目前,Redis比Memcached更流行,这里总结一下原因,共3点。


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


(2)持久化 对于Memcached来说,一旦系统宕机数据就会丢失。因为Memcached的设计初衷就是一个纯内存缓存。通过Memcached的官方文档得知,1.5.18版本以后的Memcached支持Restartable Cache(可重启缓存),其实现原理是重启时CLI先发信号给守护进程,然后守护进程将内存持久化至一个文件中,系统重启时再从那个文件中恢复数据。不过,这个设计仅在正常重启情况下使用,意外情况还是不处理。而Redis是有持久化功能的。


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


3.缓存何时存储数据


使用缓存的逻辑如下。

1)先尝试从缓存中读取数据。

2)若缓存中没有数据或者数据过期,再从数据库中读取数据保存到缓存中。

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


这种逻辑唯一麻烦的地方是,当用户发来大量的并发请求时,它们会发现缓存中没有数据,那么所有请求会同时挤在第2)步,此时如果这些请求全部从数据库读取数据,就会让数据库崩溃。

数据库的崩溃可以分为3种情况。


1)单一数据过期或者不存在,这种情况称为缓存击穿。解决方案:第一个线程如果发现Key不存在,就先给Key加锁,再从数据库读取数据保存到缓存中,最后释放锁。如果其他线程正在读取同一个Key值,那么必须等到锁释放后才行。关于锁的问题前面已经讲过,此处不再赘述。


2)数据大面积过期或者Redis宕机,这种情况称为缓存雪崩。解决方案:设置缓存的过期时间为随机分布或设置永不过期即可。


3)一个恶意请求获取的Key不在数据库中,这种情况称为缓存穿透。比如正常的商品ID是从100000到1000000(10万到100万之间的数值),那么恶意请求就可能会故意请求2000000以上的数据。这种情况如果不做处理,恶意请求每次进来时,肯定会发现缓存中没有值,那么每次都会查询数据库,虽然最终也没在数据库中找到商品,但是无疑给数据库增加了负担。这里给出两种解决办法。


比如正常的商品ID是从100000到1000000(10万到100万之间的数值),那么恶意请求就可能会故意请求2000000以上的数据。这种情况如果不做处理,恶意请求每次进来时,肯定会发现缓存中没有值,那么每次都会查询数据库,虽然最终也没在数据库中找到商品,但是无疑给数据库增加了负担。这里给出两种解决办法。


①在业务逻辑中直接校验,在数据库不被访问的前提下过滤掉不存在的Key。

②针对恶意请求的Key存放一个空值在缓存中,防止恶意请求骚扰数据库。


4)最后说一下缓存预热。上面这些逻辑都是在确保查询数据的请求已经过来后如何适当地处理,如果缓存数据找不到,再去数据库查询,最终是要占用服务器额外资源的。那么最理想的就是在用户请求过来之前把数据都缓存到Redis中。这就是缓存预热。其具体做法就是在深夜无人访问或访问量小的时候,将预热的数据保存到缓存中,这样流量大的时候,用户查询就无须再从数据库读取数据了,将大大减小数据读取压力。


相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
2天前
|
SQL 缓存 关系型数据库
MySQL技能完整学习列表6、查询优化——3、查询缓存——4、SQL优化技巧
MySQL技能完整学习列表6、查询优化——3、查询缓存——4、SQL优化技巧
65 0
|
2天前
|
缓存 NoSQL Java
SpringCache通用缓存学习
SpringCache通用缓存学习
|
6月前
|
缓存 NoSQL 关系型数据库
【Redis 系列】redis 学习十二,redis 缓存穿透,缓存击穿,缓存雪崩
【Redis 系列】redis 学习十二,redis 缓存穿透,缓存击穿,缓存雪崩
|
8月前
|
消息中间件 缓存 NoSQL
程序员快来学习缓存层场景实战数据收集—技术选型思路及整体方案
根据以上业务场景,项目组提炼出了6点业务需求,并针对业务需求梳理了技术选型相关思路。 1)原始数据海量:对于这一点,初步考虑使用HBase进行持久化。 2)对于埋点记录的请求响应要快:埋点记录服务会把原始埋点记录存放在一个缓存层,以此保证响应快速。关于这一点有多个缓存方案,稍后展开讨论。 3)可通过后台查询原始数据:如果直接使用HBase作为查询引擎,查询速度太慢,所以还需要使用Elasticsearch来保存查询页面上作为查询条件的字段和活动ID。
|
11月前
|
缓存 NoSQL Java
redis 6.0新特性-客户端缓存学习总结
redis 6.0新特性-客户端缓存学习总结
243 0
|
缓存
学习Vue3 第二十章(keep-alive缓存组件)
有时候我们不希望组件被重新渲染影响使用体验;或者处于性能考虑,避免多次重复渲染降低性能。而是希望组件可以缓存下来,维持当前的状态。这时候就需要用到keep-alive组件。
88 0
|
缓存
jira学习案例89-react-query处理服务器缓存
jira学习案例89-react-query处理服务器缓存
69 0
jira学习案例89-react-query处理服务器缓存
|
缓存
jira学习案例90-用useQuery缓存列表
jira学习案例90-用useQuery缓存列表
80 0
jira学习案例90-用useQuery缓存列表
|
缓存 运维 监控
Redis学习(十):缓存穿透、缓存击穿和缓存雪崩
key对应的数据在数据源中并不存在,每次针对此key的请求从缓存获取不到,这些请求都会压入数据源中,从而可能压垮数据源。
112 0
Redis学习(十):缓存穿透、缓存击穿和缓存雪崩
|
SQL 存储 XML
Mybatis 高阶学习(映射文件深入、延迟加载、缓存、注解开发等)
Mybatis 高阶学习(映射文件深入、延迟加载、缓存、注解开发等)
274 0
Mybatis 高阶学习(映射文件深入、延迟加载、缓存、注解开发等)