超强Redis基础学习 优化 使用 常见问题

问题大纲

为什么Redis可以这么快?

它是纯内存操作,内存本身就很快

其次,它是单线程的,Redis服务器核心是基于非阻塞的IO多路复用机制,单线程避免了多线程的频繁上下文切换问题

Redis的持久化机制

Redis提供了持久化机制给我们用,分别是RDB和AOF

RDB指的就是:根据我们自己配置的时间或者手动去执行BGSAVE或SAVE命令,Redis就会去生成RDB文件,实际上就是一个经过压缩的二进制文件,Redis可以通过这个文件在启动的时候来还原我们的数据

AOF则是把Redis服务器接收到的所有写命令都记录到日志 Redis重跑一遍这个记录下的日志文件,就相当于还原了数据

RDB会执行SAVE或BESAVE命令,redis单个线程处理会导致低效率吗?

BGSAVE命令实际上会fork出一个子进程来进行完成持久化(生成RDB文件)

在fork的过程中,父进程(主线程)肯定是阻塞的。fork完之后,是fork出来的子进程去完成持久化,因此即使是单线程,效率也不会很低

其实Redis在较新的版本中,有些地方都使用了多线程来进行处理, 只不过,核心的处理命令请求和响应还是单线程

主从架构

为了Redis「高可用」,现在基本都会给Redis做「备份」:多启一台Redis服务器,形成「主从架构」

「从服务器」的数据由「主服务器」复制过去,主从服务器的数据是一致的

如果主服务器挂了,那可以「手动」把「从服务器」升级为「主服务器」,缩短不可用时间

「主服务器」是如何把自身的数据「复制」给「从服务器」的呢

「复制」也叫「同步」,在Redis使用的是「PSYNC」命令进行同步,该命令有两种模型:完全重同步和部分重同步

如果是第一次「同步」或者切换目标同步,数据差距过大,那就会采用「完全重同步」模式进行复制;如果只是由于网络中断,只是「短时间」断连,那就会采用「部分重同步」模式进行复制

(假如主从服务器的数据差距实在是过大了,还是会采用「完全重同步」模式进行复制)

缓存穿透

原因:入侵者大量查询不存在的数据 使得Redis不断去访问数据库 然而Redis也无法缓存,就导致每次都会查询数据库...数据库的并发度不高 就会宕机

解决办法

布隆过滤器:作用:拦截不存在的数据

布隆过滤器 原理:把数据的id通过多次哈希计算标记数组,新来个数据就计算哈希,看是否能验证标记,但是会有以下的误判情况

缓存击穿

某一个key设置了过期时间,当key过期的时候,恰好对这个key有大量的并发请求,导致所有的请求都落到数据库上 这些请求可能会瞬间把DB压垮

解决方案

互斥锁
逻辑过期:数据不一定完全准确,但性能方面很优

缓存雪崩

统一时段内大量的缓存key同时失效或者Redis服务

双写一致性

有两种考察情况:

一种是要求实时性很高的

一种是允许延时一致(即延时以后再数据一致,不严格要求)

延迟双删---延时一致方案

有缺陷,但是面试爱问,如果只删除一次缓存,那么无论什么顺序都有可能脏读

而且,其实三步清除缓存也仍然有概率脏读

MQ很适用于延时一致的业务,具体用以下方式实现

互斥锁方案---要求强一致性的方案

共享锁(读锁):加锁以后只能共享读操作

排他锁(写锁):加锁以后阻塞其他读写操作,仅当前线程进行写操作

Redis集群

使用集群的原因

redis服务器升级至一定程度后 持久化的成本过高

当 Redis 需要持久化数据时,它需要将数据从内存中写入磁盘,这个过程会产生一定的性能开销。

Redis 的 RDB(Redis DataBase)持久化机制是通过 fork 子进程来实现的。当 Redis 需要持久化数据时,它会 fork 一个子进程,然后让子进程将数据写入一个临时文件。当持久化过程完成后,Redis 会使用这个临时文件来替换旧的 RDB 文件。

然而,如果 Redis 使用的内存过大,fork 子进程的过程可能会导致主线程阻塞时间过长。这是因为 fork 子进程需要复制父进程的内存空间,如果内存空间过大,这个过程就会变得非常耗时。因此,如果 Redis 使用的内存过大,就可能会导致主线程在 fork 子进程时阻塞过长时间,从而降低了 Redis 的性能。

集群解决方案

Redis Cluster是一个用于实现Redis集群的解决方案,它能够避免哨兵机制复杂的Master监控与选举操作,并方便地实现数据的分片处理,以提供更加高效的Redis解决方案。

Redis Cluster把所有的数据划分为16384个不同的槽位,并可以根据机器的性能把不同的槽位分配给不同的Redis实例。每个节点都与其他节点有关联,只需获得一个节点的信息,其他节点的信息也就可以获取到。

这些槽位被称作哈希槽,通过hash算法分配槽位,放入要缓存的数据

每个实例都会向其他实例/传播/自己负责的哈希槽,这样每台redis实例都记录有所有的关系信息了! 有了这样的映射关系,客户端也就知道去哪个实例上操作了

集群新增或者删除实例

当发生了删除或者新增时, 那么redis实例负责的哈希槽关系会发生变化

但是客户端是无感知的,因为客户端会发送请求到原来的redis实例

原来的实例会给出moved命令,告诉客户端重定向

客户端收到以后就会去新的实例请求, 并且更新本地缓存

总的来说就是

如果集群Redis实例存在变动,由于Redis实例之间会「通讯」

所以等到客户端请求时,Redis实例总会知道客户端所要请求的数据在哪个Redis实例上

如果已经迁移完毕了,那就返回「move」命令告诉客户端应该去找哪个Redis实例要数据,并且客户端应该更新自己的缓存(映射关系)

如果正在迁移中,那就返回「ack」命令告诉客户端应该去找哪个Redis实例要数据

为什么是16384个哈希槽?

「服务端 路由」的大致原理

服务端路由一般指的一种代理层, 专门对接客户端的请求 ,然后转发到Redis集群进行处理

现在比较流行的是Codis

它与Redis Cluster最大的区别是,Redis Cluster是直连Redis实例,而Codis则客户端直连Proxy,再由Proxy进行分发到不同的Redis实例进行处理

在Codis对Key路由的方案跟Redis Cluster很类似,Codis初始化出1024个哈希槽,然后分配到不同的Redis服务器中 哈希槽与Redis实例的映射关系由Zookeeper进行存储和管理

扩容Codis Redis实例的流程是怎么样的?

1.「原实例」某一个Solt的部分数据发送给「目标实例」。2.「目标实例」收到数据后,给「原实例」返回ack。3.「原实例」收到ack之后,在本地删除掉刚刚给「目标实例」的数据。4.不断循环1、2、3步骤,直至整个solt迁移完毕

Codis也是支持「异步迁移」的,针对上面的步骤2,「原实例」发送数据后,不等待「目标实例」返回ack,就继续接收客户端的请求。

未迁移完的数据标记为「只读」,不会影响到数据的一致性。如果对迁移中的数据存在「写操作」,那会让客户端进行「重试」,最后会写到「目标实例」上

相关推荐
2401_8576009515 分钟前
企业OA管理系统:Spring Boot技术实践与案例分析
java·spring boot·后端
running up that hill19 分钟前
数据库中的增删改查操作、聚合函数、内置函数、分组查询
java·数据库·sql·mysql
潜洋23 分钟前
Spring Boot 教程之六:Spring Boot - 架构
java·spring boot·后端·架构
希忘auto27 分钟前
详解RabbitMQ在Ubuntu上的安装
java·rabbitmq
铅华尽34 分钟前
Java---JDBC案例--手机信息管理系统
java·开发语言·智能手机
凌虚(失业了求个工作)34 分钟前
RAG 示例:使用 langchain、Redis、llama.cpp 构建一个 kubernetes 知识库问答
人工智能·redis·python·langchain·llama
小码的头发丝、39 分钟前
Maven的安装与配置
java·数据库·maven
说书客啊1 小时前
计算机毕业设计 | SpringBoot+vue线上家具商城 家居商品购买系统(附源码+论文)
java·spring boot·node.js·vue·毕业设计·智能家居·课程设计
小阿龙...1 小时前
创建mapreduce项目使用maven
java·ide·hadoop·spark·big data
疯一样的码农1 小时前
使用命令行创建 Maven 项目
java·maven