Redis详解(redis线程模式、数据持久化机制、主从复制、缓存穿透、缓存击穿等)

一.redis概述

redis主要用作数据库、缓存和消息中间件, 支持多种语言, 是基于内存的key-value数据结构存储系统.

redis支持数据的持久化, 可以将内存中的数据保存在磁盘中, 重启的时候可以再次加载进行使用.

redis不仅仅支持key-value数据结构, 还支持list, set, hash等数据结构.

redis支持数据的备份,即master-slave(主-从)模式的数据备份.

二.redis线程模型

在redis6.x之前是真正的单线程, 对外提供的键值存储服务也是单线程的, 整个网络IO和数据读写操作都是由单线程完成的.

在redis6.x之后引入的多线程指的是网络的请求时多线程的, 但是读写数据的读写操作还是单线程的, 所以redis是并发安全的.

那么为什么redis是单线程的执行速度还那么快呢?

1.redis是基于内存操作的, 所有的运算都是内存级别的, 查找和操作的时间复杂度都是O(1), 所以cpu不是redis的瓶颈, 所以它的性能比较高.

2.底层数据结构简单, 是hash表, 查找和操作的时间复杂度都是O(1)的.

3.redis使用的是I/O多路复用监听多个socket连接客户端, 是的一个线程来处理多个情况, 减少线程切换带来的开销, 同时也避免了I/O阻塞操作, 大大提高了redis的性能

4.因为单线程模型, 避免了不必要的上下文切换和多线程的竞争.

全局的hash表:

hash 可以在 O(1)的时间内计算出 hash 值并且找到对应的 entry 位置,entry里面是一个一个 key 指针和 value 指针,其实还有其他信息。这也是 redis 之所以性能高的原因之一.

三.redis持久化

Redis 是一个内存数据库,数据保存在内存中,但是我们都知道内存的数据变化是很快的,也容易发生丢失。Redis 还为我们提供了持久化的机制,分别是RDB(Redis DataBase)和 AOF(Append Only File).

在我们安装了 redis 之后,所有的配置都是在 redis.conf 文件中,里面保存了 RDB 和 AOF 两种持久化机制的各种配置。当符合一定条件时 Redis 会自动将内存中的数据进行快照并持久化到硬盘。

1.RDB方式

rdb持久化就是在指定的时间间隔内将内存中的数据集快照写入磁盘,也是默认的持久化方式,这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为 dump.rdb。 在redis.conf中有触发快制造快照的条件:

如下配置: save 900 1 :表示 900 秒钟内至少 1 个键被更改则进行快照。

save 300 10 :表示 300 秒内至少 10 个键被更改则进行快照。

save 60 10000 :表示 60 秒内至少 10000 个键被更改则进行快照。

在redis客户端模式中,使用shutdown save 命令在关闭redis服务时,保存快照

重新启动redis服务时,把dump.rdb文件内容还原回来.

2.AOF方式

以日志的形式来记录每个写操作,将 Redis 执行过的所有指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis 启动之初会读取该文件重新构建数据,换言之,redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作.

appendfsync always #每次修改都会 sync 消耗性能

appendfsync everysec #每秒执行一次 sync,可能会丢失这1s 的数据(默认)

定期结合mysql,人为的定期将数据写入到mysql中

四.redis事务

redis事务,是将多条命令放入到一个队列中,按顺序执行, 保证多条命令,在同一个事务中执行.

不受其他客户端的影响.

redis事务操作:

multi 开启事务

命令1

命令2

命令3 把命令加入到一个队列中,并没有立即执行

exec 执行事务

但是事务不保证同一事物中多条命令执行的原子性,即使命令有错误也会添加到队列中,执行报错也不影响其他命令执行.

redisTemplate.multi();开启事务
        ValueOperations valueOperations = redisTemplate.opsForValue();
        valueOperations.set();
        valueOperations.set();
        valueOperations.set();
     redisTemplate.exec();执行事务

五.主从复制

是指将一台 Redis 服务器的数据,复制到其他的 Redis 服务器。前者称为主节点(master),后者称为从节点(slave),数据的复制是单向的,只能由主节点到从节点。使用一个 Redis 实例作为主机,其余的作为备份机。主机和备份机的数据完全一致,主机支持数据的写入和读取等各项操作,而从机则只支持与主机数据的同步和读取。也就是说,客户端可以将数据写入到主机,由主机自动将数据的写入操作同步到从机。主从模式很好的解决了数据备份问题,并且由于主从服务数据几乎是一致的,因而可以将写入数据的命令发送给主机执行,而读取数据的命令发送给不同的从机执行,从而达到读写分离的目的。

即使期间,有一台服务器出现问题,其他redis服务也可以正常工作.当有问题的服务故障排除后,可以继续在集群中工作.

那么要实现redis主从复制的安全性, 肯定避免不了数据冗余, 服务器冗余的问题

主从复制的作用有:

负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写 Redis 数据时应用连接主节点,读 Redis 数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高 Redis 服务器的并发量.

高可用(集群)基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是 Redis 高可用的基础

redis主从集群不提供容错和恢复的功能, 一旦主节点挂了, 不会自动选取出新的master, 导致客户端所有的写请求都失败, 所以redis提供了哨兵机制, 解决了恢复的功能,但是存在在线扩容的问题, 于是就有了第三种集群方式---redis cluster

redis cluster

实现了redis分布式存储, 也就是每一个节点存储不同的数据, 实现数据分片的功能, 在redis cluster中引入了slot槽, 来实现数据分片, slot的整体取值范围为0----16383, 每个节点会分配一个slot空间, 当我们存取key的时候, redis会根据key计算一个slot值, 找到对应节点进行数据读写操作. 从集群架构来说, redis cluster是一个多主多从的集群, 只有在redis服务器宕机之后在会工作.

哨兵机制:

哨兵模式是一种特殊的模式,首先 Redis 提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待 Redis 服务器响应,从而监控运行的多个 Redis 实例。

它可以通过一套选举机制,在多台从机中选取一台作为主机, 当主机故障恢复后,临时主机又变为从机角色.

六.Key 过期策略

1. 立即删除。在设置键的过期时间时,创建一个回调事件,当过期时间达到时,由时间处理器自动执行键的删除操作。立即删除能保证内存中数据的最大新鲜度,因为它保证过期键值会在过期后马上被删除,其所占用的内存也会随之释放。但是立即删除对 cpu 是最不友好的。因为删除操作会占用 cpu 的时间.

2. 惰性删除。惰性删除是指,某个键值过期后,此键值不会马上被删除,而是等到下次被使用的时候,才会被检查到过期,此时才能得到删除。所以惰性删除的缺点很明显:浪费内存。dict 字典和 expires 字典都要保存这个键值的信息。

3. 定时删除。每隔一段时间,对 expires 字典进行检查,删除里面的过期键。可以看到,第二种为被动删除,第一种和第三种为主动删除,且第一种实时性更高。每隔一段时间执行一次删除操作,并通过限制删除操作执行的时长和频率,来减少删除操作对 cpu 的影响。另一方面定时删除也有效的减少了因惰性删除带来的内存浪费。

redis 使用的过期键值删除策略是:惰性删除加上定期删除,两者配合使用。

七.缓存穿透、缓存击穿、缓存雪崩

首先看一下缓存处理流程:

1.缓存穿透

我们要查询的数据在数据库中本身就是不存在的, 那么redis中也是不存在的, 每次查询的请求都会直接进入到数据库中.

2.缓存击穿

前提是数据库中有数据, 在某个时间点上, 热点key过期了, 而这时有大量的请求, 如果没有任何的限制, 全都进入到redis中,但是redis中的key已经过期, 所有的请求都会直接进入到数据库中, 导致mysql被压垮

解决的方法:

1.合理的设置过期的时间

2.加锁, redis中如果为空, 等第一个请求的数据进入到缓冲池中时, 再让其他请求从缓存中获取数据.

3.缓存雪崩

大量的key过期,或者缓存出现故障,导致大量的请求到达mysql

解决办法:

1.设置随机过期时间

2.把热点key,放在不同的从机

3.设置不过期

4.定时任务,将快过期的key,重新放入到缓存

对于“Redis 宕机,请求全部走数据库”这种情况,我们可以有以下的思路:

事发前:实现 Redis 的高可用(主从架构+Sentinel(哨兵),尽量避免 Redis挂掉这种情况发生。

事发中:万一 Redis 真的挂了,我们可以设置本地缓存(ehcache)+限流,尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)

事发后:redis 持久化,重启后自动从磁盘上加载数据,快速恢复缓存数据。

猜你喜欢

转载自blog.csdn.net/weixin_71243923/article/details/129779151