redis重点总结
在正常的业务流程中,用户发送请求,然后到缓存中查询数据。如果缓存中不存在数据的话,就会去数据库查询数据。数据库中有的话,就会更新缓存然后返回数据,数据库中也没有的话就会给用户返回一个空。
1.缓存击穿
1.1概念
缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库去取数据,引起数据库压力瞬间增大,造成过大压力。和缓存雪崩不同的是,缓存击穿是指并发查同一条数据,缓存雪崩是不同数据都过期了,很多数据都查不到从而查数据库。
1.2解决方案
- 设置热点数据永远不过期。(常用
- 加互斥锁,进行排队
2.缓存雪崩
2.1概念
缓存雪崩是指缓存同一时间大面积的失效或者缓存服务器宕机,所以,后面的请求都会落到数据库上,造成数据库短时间内承受大量请求而崩掉。
2.2解决方案
- 缓存数据的过期时间设置随机,防止同一时间大量数据过期现象发生。(常用
- 一般并发量不是特别多的时候,使用最多的解决方案是加锁排队。
- 给每一个缓存数据增加相应的缓存标记,记录缓存的是否失效,如果缓存标记失效,则更新数据缓存。
3.缓存穿透
3.1概念
缓存穿透是指缓存和数据库中都没有的数据,导致所有的请求都落到数据库上,造成数据库短时间内承受大量请求而崩掉。
3.2解决方案
- 接口层增加校验,如用户鉴权校验,id做基础校验,id<=0的直接拦截;
- 从缓存取不到的数据,在数据库中也没有取到,这时也可以将key-value对写为key-null,缓存有效时间可以设置短点,如30秒(设置太长会导致正常情况也没法使用)。这样可以防止攻击用户反复用同一个id暴力攻击
- 采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的 bitmap 中,一个一定不存在的数据会被这个 bitmap 拦截掉,从而避免了对底层存储系统的查询压力
4.主从复制原理
实现主从复制 ( Master-slave Replication)的工作原理 :
- slave从节点服务启动并连接到Master之后,它将主动发送一个SYNC命令
- Maser服务主节点收到同步命令后将启动后台存盘进程,同时收集所有接收到的用于修改数据集的命令,在后台进程执行完毕后。Mastr将传送整个数据库文件到Slave,以完成一次完全同步
- 而slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中
此后,Master主节点继续将所有已经收集到的修改命令,和新的修改命令依次传送给Slaves,slave将在本次执行这些数据修改命令,从而达到最终的数据同步。
如果Master和Slave之间的链接出现断连现象,Slave可以自动重连Master,但是在连接成功之后,一次完全同步将被自动执行。
5.Redis持久化
Redis是基于内存存储的nosql数据库 但是也可以持久化数据到硬盘当中
redis有两种持久化方式,分别是 rdb 和 aof
5.1rdb
rdb的触发方式分为两种:自动触发、手动触发
优点:存储的数据是按照二进制形式进行存储,比较紧凑,存储和恢复都比较快
缺点:当进行存盘的时候,在存盘开始到存盘完成的这段时间的数据,并没有立即的持久化到硬盘当中,如果服务器宕机,就可能发生数据丢失。
5.1.1手动触发
rdb在手动触发当中呢,使用的主要是save和bgsave命令。
1.save
save命令执行后,会阻塞当前服务器,知道RDB完成为止,但是当你数据量大的时候,就会出现造成过长时间的阻塞
2.bgsave
bgsave命令执行后,Redis的主进程就会fork一个子进程来完成RDB的过程,完成后自动结束。所有使用bgsave时,造成主进程阻塞的时间只为fork阶段的那一下。与save相比,阻塞时间短。
5.1.2自动触发
场景一:可通过配置redis.conf文件,定义触发规则使得rdb自动执行
比如 save 900 1 表示 在900s内,至少执行了一次写操作,就会自动触发bgsave
场景二:在执行shutdown命令时,如果没有开启AOF持久化功能,那么就会自动执行一次bgsave
场景三:主从同步(master和slave建立同步机制
5.2aof
aof的触发方式也分为 自动触发和手动触发
优点:aof存储中,数据丢失的少,精准度高
缺点:存储的文件越来越大 需要瘦身 恢复数据也慢
5.2.1手动触发
执行 bgrewriteaof命令。 该命令会使主进程 redis-server 创建出一个子进程 bgrewriteaof,由该子进程完成 rewrite过程。而在 rewrite 期间,redis-server 仍是可以对外提供读写服务的。
5.2.2自动触发
修改配置文件
首先指定aof文件的名称。
AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis 最多也就丢失 1 秒的数据而已。
5.3AOF与RDB对比
- RDB快照的存储是全量存储,每次执行时,会将数据以二进制流的方式全部存储到硬盘当中。
- AOF是增量存储,他存储的是数据库中每次进行数据修改时的命令,将命令以增量的方式存储在硬盘当中。他的恢复也是将命令从头到尾执行一遍进行恢复。
在Redis 4.0版本后采用混合模式
在正常的存储过程中采用RDB快照的方式,而当RDB执行时,采用AOF存储,这样既提高了数据存储和恢复的效率,也减少了丢失的数据(并不是不会丢失)。
6.Redis的key过期策略
过期策略通常有以下三种
- 定时过期:每个设置过期时间的key都需要创建一个定时器,到过期时间就会立即清除。该策略可以立即清除过期的数据,对内存很友好;但是会占用大量的CPU资源去处理过期的数据,从而影响缓存的响应时间和吞吐量。
- 惰性过期:只有当访问一个key时,才会判断该key是否已过期,过期则清除。该策略可以最大化地节省CPU资源,却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问,从而不会被清除,占用大量内存。
- 定期过期:每隔一定的时间,会扫描一定数量的数据库的expires字典中一定数量的key,并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
7.Redis的内存淘汰机制
Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时,怎么处理需要新写入且需要申请额外空间的数据。
全局的键空间选择性移除
- noeviction:当内存不足以容纳新写入数据时,新写入操作会报错。
- allkeys-lru:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的key。(这个是最常用的)
- allkeys-random:当内存不足以容纳新写入数据时,在键空间中,随机移除某个key。
设置过期时间的键空间选择性移除
-
volatile-lru:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,移除最近最少使用的key。
-
volatile-random当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,随机移除某个key。
的键空间选择性移除 -
volatile-lru:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,移除最近最少使用的key。
-
volatile-random当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,随机移除某个key。
-
volatile-ttl当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,有更早过期时间的key优先移除。