Redis缓存和持久化

重开之Java程序员

已于 2024-02-10 20:53:19 修改

阅读量262

点赞数

文章标签： java redis

于 2023-09-03 12:20:37 首次发布

本文链接：https://blog.csdn.net/weixin_51971817/article/details/132647354

版权

Redis缓存

什么是缓存

缓存就是数据交换的缓冲区(称作Cache),是存贮数据的临时地方,一般读写性能较高

缓存的作用

降低后端负载
提高读写效率,降低响应时间

缓存的成本

数据一致性成本
代码维护成本
运维成本

缓存更新策略

业务场景

低一致性需求：使用内存淘汰机制。例如店铺类型的查询缓存
高一致性需求：主动更新，并以超时剔除作为兜底方案。例如店铺详情查询缓存

数据库与缓存不一致的问题

因为我们的缓存的数据来自数据库，但是数据库中的数据是会变的，如果当数据库的数据发生变化，而缓存却没有同步，此时就有一致性的问题。

解决方法我们可以采用人工编码方式进行处理一致性的问题

数据库和缓存不一致采用什么方案

我们采用人工编码的方案，但是需要考虑三个问题

删除缓存还是更新缓存？
- 更新缓存：每次更新数据库都要进行更新缓存，无效的写操作太多了（写多读少的时候）
- 删除缓存：更新数据库的时候让缓存失效，查询的时候在更新缓存
如何保证缓存与数据库的操作同时成功或者失败？
- 单体系统，将缓存和数据库操作放在一个事务中
- 分布式系统，利用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时