目录
Redis缓存
什么是缓存
缓存就是数据交换的缓冲区(称作Cache),是存贮数据的临时地方,一般读写性能较高
缓存的作用
-
降低后端负载
-
提高读写效率,降低响应时间
缓存的成本
-
数据一致性成本
-
代码维护成本
-
运维成本
缓存更新策略![](https://i-blog.csdnimg.cn/blog_migrate/73807fad98e56db4defccdbabbac6a9f.png)
业务场景
-
低一致性需求:使用内存淘汰机制。例如店铺类型的查询缓存
-
高一致性需求:主动更新,并以超时剔除作为兜底方案。例如店铺详情查询缓存
数据库与缓存不一致的问题
因为我们的缓存的数据来自数据库,但是数据库中的数据是会变的,如果当数据库的数据发生变化,而缓存却没有同步,此时就有一致性的问题。
解决方法我们可以采用人工编码方式进行处理一致性的问题
数据库和缓存不一致采用什么方案
我们采用人工编码的方案,但是需要考虑三个问题
-
删除缓存还是更新缓存?
-
更新缓存:每次更新数据库都要进行更新缓存,无效的写操作太多了(写多读少的时候)
-
删除缓存:更新数据库的时候让缓存失效,查询的时候在更新缓存
-
-
如何保证缓存与数据库的操作同时成功或者失败?
-
单体系统,将缓存和数据库操作放在一个事务中
-
分布式系统,利用TCC等分布式事务方案
-
-
先操作缓存还是先操作数据库?
-
先删除缓存,再操作数据库
-
先操作数据库,再删除缓存
-
缓存穿透
缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远不会生效,这些请求都会到数据库.
常见的解决方案
-
缓存空对象
优点:实现简单,维护方便
缺点:额外的内存消耗 可能造成短期的不一致
-
布隆过滤
底层是一个byte数组,将数据经过某种哈希算法计算,存储到布隆过滤器中
优点:内存占用较少,没有多余key
缺点:实现复杂 存在误判的可能(不存在真不存在,存在不一定存在)
-
增强id的复杂度,避免被猜测id规律
-
做好数据的基础格式校验
-
加强用户权限校验
缓存雪崩
缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机,导致大量请求到达数据库,带来巨大压力.
解决方案
-
给不同的Key的TTL添加随机值
-
利用Redis集群提高服务的可用性
-
给缓存业务添加降级限流策略
-
给业务添加多级缓存
缓存击穿
缓存击穿问题也叫热点Key问题,就是一个被高并发访问并且缓存重建业务较复杂的Key突然失效了,无数的请求访问会再瞬间给数据库带来巨大的的冲击
解决方案
-
互斥锁
-
优点:
没有额外的内存消耗
保证一致性
实现简单
-
缺点:
线程需要等待,性能受影响
可能有死锁风险
-
-
逻辑过期
-
优点:线程无需等待,性能较好
-
缺点:
不保证一致性
有额外的内存消耗
实现复杂
-
Redis持久化
Redis有两种持久化方案:
-
RDB持久化
-
AOF持久化
RDB持久化
RDB全称Redis Database Backup file(Redis数据备份文件),也被叫做Redis数据快照.简单来说就是把内存中的所有数据都记录到磁盘中.当Redis实例故障重启后,从磁盘读取快照文件,恢复数据.
执行时机
RDB持久化在四种情况下执行:
-
执行save命令
-
执行bgsave命令
-
Redis停机时
-
触发RDB条件时
RDB方式bgsave的基本流程
-
fork主进程得到一个子进程,共享内存空间
-
子进程读取内存数据并写入新的RDB文件
-
用新RDB文件替换旧的RDB文件
RDB默认是服务停止时会执行
缺点:
-
RDB执行间隔时间长,两次RDB之间写入数据有丢失的风险
-
fork子进程,压缩,写出RDB文件都比较耗时
AOF持久化
AOF全称为Append Only File(追加文件).Redis处理的每一个写命令都会记录在AOF文件,可以看做是命令日志文件.
AOF因为是记录命令,AOF文件会比RDB文件大的多.而且AOF会记录同一个key的多次写操作,但是只有最后一次写操作才是有意义的.
这里我们可以通过执行bgrewriteaof命令,可以让AOF文件执行重写功能,用最少的命令达到相同的效果
RDB和AOF的对比
Redis主从
单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就要搭建主从集群,实现读写分离
数据同步原理
主从第一次同步是全量同步:
master如何判断slave是不是以第一次来同步数据?这里会用到两个很重要的概念:
-
Replication Id:简称replid,是数据集的标记,id一致则说明是同一数据集.每一个master都有唯一的replid,slave会继承master节点的replid
-
offset:偏移量,随着记录在repl_baklog中的数据多而逐渐增大.slave完成同步时也会记录当前同步的offset,如果slave的offset < master的offset,说明slave数据需要更新了
slave也会有自己的replid和offset.
完整流程描述:
-
slave节点请求增量同步
-
master节点判断replid,发现不一致,拒绝增量同步
-
master将完整内存数据生成RDB,发送RDB到slave
-
slave清空本地数据,加载master的RDB
-
master将RDB期间的命令记录在repl_baklog,并持续将log中的命令发送给slave
-
slave执行接收到的命令,保持与master之间的同步
但如果slave重启后同步,则执行增量同步
什么是增量同步?就是只更新slave与master存在差异的部分数据。
总结
简述全量同步和增量同步区别?
-
全量同步:master将完整内存数据生成RDB,发送RDB到slave。后续命令则记录在repl_baklog,逐个发送给slave。
-
增量同步:slave提交自己的offset到master,master获取repl_baklog中从offset之后的命令给slave
什么时候执行全量同步?
-
slave节点第一次连接master节点时
-
slave节点断开时间太久,repl_baklog中的offset已经被覆盖时
什么时候执行增量同步?
-
slave节点断开又恢复,并且在repl_baklog中能找到offset时
-