文章目录
引言
- 感觉进度还是不够快,然后方向有点乱,又是项目,又是八股,又是redis,做项目发现很多没有学过。本来放下了redis,准备直接做项目,结果看着看着,发现redis这里有不会。
正文
缓存基础
- 将MySQL中的热点数据存储在Redis上,利用其访问高效的特点
- 二八原则,百分之八十的流量建立在百分之二十的信息上。
怎么做
- 采用服务端缓存,访问MySQL数据之后的将数据放在redis中进行缓存,下次直接访问redis
缓存的几种模式
- 旁路缓存模式(Cache-Aside Pattern):这个用的最多
- 读穿透模式
- 写穿透模式
- 异步缓存写入模式
旁路缓存模式(重点)
-
应用服务直接将缓存当作数据的旁路,直接和缓存进行交互
-
读取数据的流程
- 读取数据先读取缓存,缓存中有,那就加载缓存
- 缓存中没有读取数据库,然后将读取的数据放入缓存中
- 会预先加载一批数据到缓存中。
-
写数据流程
- 直接更新数据库,然后删除缓存
如果不删除缓存,会出现时序性的问题
-
更新修改数据库和修改缓存的顺序不一样。
-
适用场景和缺点
- 读多血少
- 出现缓存和数据库不一致的情况
读穿透(了解)
- 应用服务不在和缓存直接交互,而是直接访问数据服务(代理)
- 由数据服务访问数据库和缓存,使用者不知道数据来源,数据服务会根据情况查询缓存或数据库
特点
- 服务对于缓存是透明,代码更加简洁
- 命中性能不如旁路缓存模式,还多了一次服务间调用。
写穿透(了解)
- 一个缓存一个数据库,更新操作比较麻烦,先更新数据库,在删除缓存
- 应用程序访问存储服务源,然后存储服务源完成对应的缓存和数据库操作
具体应用
- 写穿透配合读穿透使用
- 对缓存及时性要求高
- 不能忍受丢失数据和数据不一致。
异步缓存写入模式
- 同写穿透,不过先写缓存,然后异步写入数据库,
写入方式
- 收集写操作,在数据库负载低的时候慢慢写入
- 一个批量一块写入
优点
- 降低了请求延迟,减轻了数据库复旦
- 安全性不够,系统崩溃,内存数据会丢失
面试重点
Redis缓存是如何应用的
- 旁路缓存,先查询redis,没有的话,再查MySQL,并将数据加载到Redis
Redis设置缓存用什么命令
- set key value,如果业务要增加一个过期时间,可以使用ex参数,set key value ex 10;
聊聊旁路缓存模式下的查询流程
- 请求到后台服务之后,先查redis,有就返回数据,没有就查Mysql,并将mysql的数据存入redis,最后返回给用户。
缓存异常场景
缓存穿透
- 缓存和数据库中都没有的数据,而用户不断发起请求 。
- 缓存是被动写的,也就是查不到就去数据库查,然后把数据插入到缓存中,现在就是每次都是查缓存,在数据库也查不到,缓存就被击穿了。
- 有人频繁利用这类DB中没有的数据不断访问,系统会崩溃
解决方案
- 接口层校验,对于访存数据做基础校验
- 对于取不到的数据,设置为key-null,并设置有效时间较短,防止用户在短时间内反复用同一个id暴力攻击
- 布隆过滤器 ,用于快速判定某一个元素是否在数据库中。
- 将字符串通过hash函数映射到不同的二进制位置,并将该位置设置为1
- 空间时间都很小,但是不完全准
缓存击穿
- 缓存中没有,但是数据库中有的数据。
- 某一瞬间并发用户特别多,同时读缓存没有读到数据,又同时去数据库读取数据,压力瞬间增加,崩溃
解决方案
- 热点数据续期,对于持续访问的数据不断续期,避免过期失效被击穿
- 进程加互斥锁,重建缓存
- 线程查询缓存发现缓存不存在,尝试对线程加锁,拿到锁的线程访问数据库,并重建缓存,其他循环重试。
缓存雪崩
- 大量的应用请求因为异常无法在Redis缓存中进行处理,像雪崩一样,直接打到数据库上。
- 雪崩的原因
- 数据大批量到过期时间
- 查询数据量巨大,引起数据库压力过大,甚至宕机
和缓存击穿的区别
- 缓存击穿是一条热点数据在Redis没有得到及时重建,
- 缓存雪崩是一大批数据在Redis中同时失效
解决方案
- 缓存过期时间设置随机,防止同一时间大量数据过期现象发生
- 加互斥锁重建缓存
- 当线程查询缓存发现数据不存在事,加锁,多个线程抢锁,拿到锁的线程查询数据库,重建缓存,失败则循环重试。
面试重点
缓存击穿和缓存穿透有什么区别
- 击穿是单个热点数据在缓存中不存在,但是在数据库中存在,数据库被一瞬间的流量击垮的场景
- 穿透是某个key不在数据库也不在缓存中,被海量击打
缓存雪崩和缓存击穿有什么区别
- 缓存适量的数量,击穿是一个key失效,雪崩是大量的key 失效。
缓存击穿怎么解决
- 热点数据续期
- 加锁重建缓存,防止MySQL被击穿。
缓存一致性怎么保证?
缓存一致性问题是什么
- 缓存是数据库的冗余存储,如果数据库信息更改了,缓存的数据和数据库不一致怎么办?
- 解决办法
- 更新MySQL即可,不管Redis,以过期时间兜底
- 更新MySQL之后,操作Redis
- 异步将MySQL更新同步到Redis
仅仅更新MySQL,不管Redis,过期时间兜底
- 仅仅更新MySQL,等redis过期了,自动从MySQL重建更新,在这段时间内数据是不一致的。
- 时间太长,会产生很多脏数据
- 时间太短,会出现缓存击穿
优点
- redis原生接口,开发成本低,易于实现,直接使用ex
- 管理成本低,出概率的问题较小
缺点
- 完全依赖过期时间,时间太短容易造成缓存频繁失效,太长会有较长的时间不一致。
更新MySQL,立刻更新Redis
- 除了使用过期时间进行兜底,还会将缓存数据直接删除,借此减少数据不一致的情况出现
优点
- 想对方案一,达成最终一致性的延迟更小
- 实现成本低,只是在方案一的基础上,增加了删除的逻辑
不足
- 更新mysql成功,删除redis却失败,就退化为方案一
- 在更新的时候需要额外操作redis,性能损耗
异步将MySQL更新到MySQL
- 将消费服务作为mysql的一个salve,订阅mysql的binlog日志,解析日志的内容,在更新到redis中
- 业务和数据访问完全解耦,redis更新对业务更加透明(阿里的canal组件)
优点
- 和业务完全解耦,在更新mysql是,不需要额外操作
- 无时序性问题,可靠性抢。
缺点
- 成本高,引入了消息队列,还需要搭建同步服务。
- 服务崩溃了,redis没法更新。
方案选型
- 时效性要求很高,一致性要求很高,不要使用缓存
- 通常来说,使用过期兜底是行之有效的方式,还可以增加一个删除,增加时效性。
- 解耦层面,使用方案三。
面试重点
缓存一致性问题是什么?
- MySQL数据更新了,redis作为缓存,数据应该怎么保存一致性的问题。
redis做旁路缓存,如果mysql更新了,该何去何从
- 在项目中使用过期时间来兜底,并在更新DB后,增加删除操作提升一致性的问题。
- 设计方案的时候,考虑过订阅binlog日志的方式,会成本高,并且代码复杂。
什么情况下,适合订阅binlog方式
- 这种模式更像是同步数据,比较适合缓存很长时间过期、或者不过期的场景,如果一个视频网站,有几个视频流量很大,基本不会动,是稳定的,可以使用这种方式。
分布式锁
分布式锁是什么?
锁
- 针对某项资源使用权限的管理,用来控制共享资源。
分布式锁
- 在分布式场景下的锁,多台不同机器上的进程,去竞争同一项资源。
分布式锁有什么特性?
互斥性
- 只让一个竞争者持有锁,其他进程无法持有。
安全性
- 避免锁因为异常永远无法释放
- 一个进程因为异常在持有锁的时候崩溃了,所拥有的锁能够被兜底释放,保证后续其他的竞争者也能够获得锁。
对称性
- 同一个锁,加锁和解锁的必须要是用一个进程
- 不能把其他竞争者持有的锁释放了
可靠性
- 有一定程度的处理能力和容灾能力
分布式锁常用的方式什么?
最简化版本
- 使用setnx实现,因为setnx是在变量不存在的时候,设置一个新的变量,并返回1,如果变量存在,就返回0。
- 设置一个lock变量,每一次进程访问时候,就声明这个变量,操作完成之后,在删除变量,delete lock。在访问期间,其他线程通过setnx lock就会返回0,,无法访问,妙呀!
支持过期时间
- 但是上述问题,存在一个问题,就是如果获取锁的某一个线程挂掉了,那么这个锁就石沉大海了,后续的所有线程都没有办法进行访问了。所以,需要增加一个过期时间来兜底。
setnx lock 1 ex limit-times
- 即使获取锁的进程崩溃了,但是只要超过了limits-times,仍旧能够解锁,变量就过期了,其他进程仍旧能够获取锁。
但是仍旧存在一个问题,就是会出现其他进程删对应的锁的情况
增加owner字段
- 分布式锁需要满足谁申请谁释放的原则,不能释放别人的锁,分布式锁要有归属
- 在编程过程中,都是使用进程id作为锁的值
cpp
set key owner(uuid) nx ex limit-seconds
- 在获取锁的时候,会检查这个锁的值是不是自己的进程号,判定这个锁有没有变化。
引入Lua
- 上述操作都不是原子性的,通过Lua将若干操作整合为原子操作。通过lua脚本,将若干操作合并成原子操作,保证结果的一致性 。
- Lua是一个脚本
上述所有操作保证了对称性、安全性、互斥性
可靠性是如何保证的?
- 上述所有方式都是针对单机模型而言的,如果redis挂了怎么办?常见方式有两种,分别是
- 主从容灾
- 多级部署
主从容灾
- 为redis配置从节点,当主节点挂了,直接用从节点进行顶包。
- 但是主从切换需要配置哨兵模式,实现主从节点自动切换,容纳灾祸
缺点
- 主动节点数据同步需要时间,会丢掉部分数据
- 分布式锁在失效的过程,会有多个机器同时获取执行权限
多机部署
- 尝试多机部署,使用redis中的redlock
- redlock:奇数个机器进行部署,然后半数以上的机器同意加锁才能成功,可靠性会向ETCD靠拢
具体执行流程
- 有5个redis主节点,保证不会同时宕机,申请锁的时候,同时向5个主节点申请锁
- 数量超过一半同意,获取锁,如果超过一半失败,向所有redis主节点发送解锁指令
- 因为向五个节点发送锁请求,会有一个时间限制,如果在锁持有时间内,仍旧不能获取所有锁,就是失败。
优点
- 增加灾难容错率,给运维进一步增加修复时间
- 单点reids 的所有可靠性保持手段都可以使用,所以增加了可靠性
可靠性深究
没有完全可靠的分布式锁,NPC困境
N网络延迟
- 当分布式锁获得返回包的时间过长,锁会很快就过期。
- 锁剩余时间,减去请求时间,解决锁的网络延迟问题
P进程暂停
- 进程在进行垃圾回收时,锁过期了,其他进程仍旧能够获得锁,两个进程就获得了同一个分布式锁。
- GC的时间无法掌控,看门狗会随着GC而阻塞,也无法解决
C时钟漂移
- 不同机器发生时间漂移,会出现同时获得一个锁的情况,无解。
具体来说,需要配合业务开展,不是完全可靠的
面试重点
分布式锁实现要点是什么?
- 加锁的时候,要设置owner和过期时间
- owner便于解锁的时候,进行拥有者的判断
- 过期时间,对异常情况进行兜底
- 解锁的时候,要先判断owner是否是自己,是自己在释放
- 使用Lua脚本,保证操作的原子性
为什么要引入owner概念
- 分布式锁需要保证对称性,谁加锁,就谁解锁
- 具体情况说明,某一个服务执行时间太久,然后锁过期了,其他服务又获取了锁。
你提到Lua,Lua一定能够保证原子性吗?
- Lua本身不具有原子性,通过Lua保证原子性是因为Redis是单线程执行的,一个线程放进Lua来执行,相当于打包再一次,redis执行的过程中,不会被其他请求打断
分布式锁是完全可靠的吗?
- 没有完全可靠的分布式锁,关键业务需要靠幂等来兜底
- 当然也可以使用redlock集群化的分布式锁,这种模式出问题的概率很低。
事物
事物是什么?
- Mysql中的事物具有ACID原子特定,Redis不具有原子性和持久性。
- 多个操作被看作是一个整体,也就是事物。事物通常具有原子性。
Multi事物
- 通过multi关键字,进入多任务队列,执行对应的操作,后续所有输入的命令都会进入queue中
- 使用exec指令,执行queue中的所有命令
- 使用discard指令,丢弃最终的事物
- 使用watch保证事物中的变量不会丢弃和改变。
multi事物具有原子性吗
- 不具备,因为只是通过单线程的特性,其他操作切不进来
- 但是因为中途自己崩溃,或者自己的问题只做一半,就没有意义了
multi事物的缺点
- 弱原子性,事物开启之后每一个命令都是一次调用,浪费资源。
- watch难用
- 失败了还会继续执行,没意义
Lua做事物
Lua是什么
- 标准C语言编写的轻量脚本语言
- 目的是为应用程序提供扩展
Redis和Lua
- redis通过内嵌支持lua环境,执行脚本的常用命令是eval
- redis是单线程,处理过程中,不会被打断并切换到其他处理
- redis执行lua脚本具有原子性
具体执行指令
cpp
eval "return {redis.call('set' ,'ka','a1'),redis.call('icnr','ka')}"
优势
- 可以编写if-else选择逻辑
- 事物中间执行事变,会中断后续执行
- 使用方便,开启lua就可以执行事物
Lua主要是redis中干什么的
- 分布式锁和秒杀场景
消息队列
消息队列是什么?
- 传递消息的队列
- 用于
- 异步流程、消息分发、流量削峰
- 优点
- 是实现高性能、高可用和高扩展的架构
常见的消息队列中间件
- 是实现高性能、高可用和高扩展的架构
- Kafka,RabbitQ,MetaMQ等
redis能做消息队列吗
- 可以,适合做一个轻量级的消息队列,常见的有三种方案
List做消息队列
- 将数据放入list,消息作为商品,这就是一个典型的生产者和消费者模式。
- 通过rpush和lpop实现消息的传递,但是这里不知道消息队列什么时候有消息,只能轮询
BRPOP和BLPOP
- 没有消息在队列中,会陷入阻塞,阻塞时间内有消息,再继续执行。
- 缺点
- 没有ACK机制,消费失败了,还要放回去
- 不支持多人消费
Pub/Sub生产订阅模式
- 使用
subscribe channel
订阅消息频道 - 使用
publish channel msg
往特定频道发送消息
缺点
- 没有办法实现ACK功能
- 不支持持久化,redis重启消息会全部丢失,若以pub和sub适合处理不重要的消息
Stream做消息队列
- redis实现,具有持久化,消费组的功能,但是不考
几种方式对比
List:不需要ACK,不需要消费组,可以使用
PUB\SUB:不需要ACK,不需要持久化,可以用
STREAM:需要ACK,需要消费组,需要持久化,可用
秒杀
什么是秒杀
- 一瞬间产生巨大流量的场景
需要注意以下几个问题
- 海量请求,服务要抗住
- 不能超卖
- 避免少买
- 保证触达是用户不是黄牛
没有相关的要求,直接跳过
场景应用面试题
实际使用redis做什么应用
- 缓存和消息队列
redis缓存一般是如何使用的
- 旁路缓存
redis做旁路缓存了,如果Mysql做了更新,该何去何从
- 使用过期时间都低,更新DB之后,删除缓存
redis做秒杀场景可以吗
- redis因为高性能,经常被用于做秒杀产经,预扣库存,结合Lua脚本,可以在一定程度上保证预扣库存的原子性
redis可以做消息队列吗
- 可以,但是针对那种轻量级,不需要持久化,不需要ack的简单消息队列可以。
总结
- 就剩限流器和秒杀没看了,感觉比较偏,我想去的并不是这一类服务,所以还是算了把,不看了,省时间。
- 下面就是结合项目看一下项目的数据库怎么做的。