Redis缓存和持久化

目录

Redis缓存

什么是缓存

缓存更新策略​编辑

业务场景

缓存穿透

常见的解决方案

缓存雪崩

解决方案

缓存击穿

解决方案

Redis持久化

RDB持久化

执行时机

RDB方式bgsave的基本流程

AOF持久化

RDB和AOF的对比​编辑

Redis主从

数据同步原理

总结


Redis缓存

什么是缓存

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

缓存的作用

  • 降低后端负载

  • 提高读写效率,降低响应时间

缓存的成本

  • 数据一致性成本

  • 代码维护成本

  • 运维成本

缓存更新策略Redis缓存和持久化_第1张图片

业务场景

  • 低一致性需求:使用内存淘汰机制。例如店铺类型的查询缓存

  • 高一致性需求:主动更新,并以超时剔除作为兜底方案。例如店铺详情查询缓存

缓存穿透

缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远不会生效,这些请求都会到数据库.

常见的解决方案

  • 缓存空对象

    优点:实现简单,维护方便

    缺点:额外的内存消耗 可能造成短期的不一致Redis缓存和持久化_第2张图片

  • 布隆过滤

    底层是一个byte数组,存储的二进制位

    优点:内存占用较少,没有多余key

    缺点:实现复杂 存在误判的可能(不存在真不存在,存在不一定存在)Redis缓存和持久化_第3张图片

缓存雪崩

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机,导致大量请求到达数据库,带来巨大压力.

解决方案

  • 给不同的Key的TTL添加随机值

  • 利用Redis集群提高服务的可用性

  • 给缓存业务添加降级限流策略

  • 给业务添加多级缓存

缓存击穿

缓存击穿问题也叫热点Key问题,就是一个被高并发访问并且缓存重建业务较复杂的Key突然失效了,无数的请求访问会再瞬间给数据库带来巨大的的冲击

解决方案

  • 互斥锁

    • 优点:

      没有额外的内存消耗

      保证一致性

      实现简单

    • 缺点:

      线程需要等待,性能受影响

      可能有死锁风险Redis缓存和持久化_第4张图片

  • 逻辑过期

    • 优点:线程无需等待,性能较好

    • 缺点:

      不保证一致性

      有额外的内存消耗

      实现复杂Redis缓存和持久化_第5张图片

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缓存和持久化_第6张图片

Redis主从

单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就要搭建主从集群,实现读写分离

数据同步原理

主从第一次同步是全量同步Redis缓存和持久化_第7张图片

master如何判断slave是不是以第一次来同步数据?这里会用到两个很重要的概念:

  • Replication Id:简称replid,是数据集的标记,id一致则说明是同一数据集.每一个master都有唯一的replid,slave会继承master节点的replid

  • offset:偏移量,随着记录在repl_baklog中的数据多而逐渐增大.slave完成同步时也会记录当前同步的offset,如果slave的offset < master的offset,说明slave数据需要更新了

slave也会有自己的replid和offset.Redis缓存和持久化_第8张图片

完整流程描述:

  • slave节点请求增量同步

  • master节点判断replid,发现不一致,拒绝增量同步

  • master将完整内存数据生成RDB,发送RDB到slave

  • slave清空本地数据,加载master的RDB

  • master将RDB期间的命令记录在repl_baklog,并持续将log中的命令发送给slave

  • slave执行接收到的命令,保持与master之间的同步

但如果slave重启后同步,则执行增量同步

什么是增量同步?就是只更新slave与master存在差异的部分数据。Redis缓存和持久化_第9张图片

总结

简述全量同步和增量同步区别?

  • 全量同步: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时

你可能感兴趣的:(java,redis)