1.全面解析Redis-RDB与AOF持久化机制
Redis之所以能够提供高速读写操作是因为数据存储在内存中，但这也带来了一个风险，即在服务器宕机或断电的情况下，内存中的数据会丢失。为了解决这个问题，Redis提供了持久化机制来确保数据的持久性和可靠性。
Redis持久化机制：
ⅰRDB(Redis Data Base) ：内存快照
ⅱAOF(Append Only File)： 增量日志
混合持久化：RDB + AOF
RDB持久化
在指定的时间间隔内将内存中的数据集快照写入磁盘，RDB是内存快照（内存数据的二进制序列化形式）的方式持久化，每次都是从Redis中生成一个快照进行数据的全量备份。
RDB持久化流程：
2.继续处理客户端请求3.处理新的写操作主进程内存副本COW机制1.FORK子进程备份子进程共享内存2.将共享内存数据写到临时RDB文件3.完成临时文件写入,替换旧RDB文件子进程退出RDB持久化流程
RDB持久化方案进行备份时，Redis会单独fork一个子进程来进行持久化，会将数据写入一个临时文件中，持久化完成后替换旧的RDB文件。
在整个持久化过程中，主进程（为客户端提供服务的进程）不参与IO操作，这样能确保Redis服务的高性能，RDB持久化机制适合对数据完整性要求不高但追求高效恢复的使用场景。
RDB触发规则
手动触发
save：
阻塞当前 Redis进程，直到RDB持久化过程完成，如果内存实例比较大会造成长时间阻塞，尽量不要使用这方式
bgsave：
Redis主进程fork创建子进程，由子进程完成持久化，阻塞时间很短（微秒级）
自动触发
配置触发：
●在Redis安装目录下的redis.conf配置文件中搜索 /snapshot即可快速定位，配置文件默认注释了下面三行数据，通过配置规则来触发RDB的持久化，需要开启或者根据自己的需求按照规则来配置。
井井THESE EXPLICITLY BY UNCOMMENTING THE FOLLOWING LINE.YOU CAN SET SAVE 3600 1 300 60 10000# BY DEFAULT REDIS WILL STOP ACCEPTING WRITES IF F FERFRDBSNAPSHOTS ARE ENABLED
save 3600 1 -- 3600 秒内有1个key被修改，触发RDB save 300 100 -- 300 秒内有100个key被修改，触发RDB save 60 10000 -- 60 秒内有10000个key被修改，触发RDB
shutdown触发：
●shutdown触发Redis的RDB持久化机制非常简单，我们在客户端执行shutdown即可。
[ROOT@LOCALHOST BIN]#RM - RF DUMP.RDB,删除已经存在的RDB文件BIN]# REDIS-CLI -P 6379[[email protected]:6379>SHUTDOWN关闭REDIS-SERVENNOT CONNECTED> QUIT[ROOT@LOCALHOST BIN]# LLTOTAL 21556重新生成的文件JUL23:193026CONFDRWXR-XR-X.ROOTROOT12727JUL00:42DUMP.RDB1ROOT-RW-R----.ROOT5204342JUL126-RWXR-XR-X.06:56REDIS - BENCHMARKROOTROOT12JUL1REDIS-SERVER06:5626REDIS - CHECK - AOFL RWXRWXRWX.ROOTROOT12JULREDIS-SERVER2606:56REDIS - CHECK - RDBL RWXRWXRWX.ROOTROOT5421781- CLIJUL06:5626REDI!ROOTROOTRWXR-XR-X.12JULLRWXRWXRWX.06:56REDIS - SENTINELREDIS26SERVERROOTROOTROOT 11438191LNC2606:56REDIS-ROOTS - SERVERRWXR-XR-X.
flushall触发:
●flushall清空Redis所有数据库的数据（16个库数据都会被删除）（等同于删库跑路）
[ROOT@LOCALHOST BIN]# RM -RF DUMP.RDB删除RDB文件REDIS-CLI -P 6379BIN]#[[email protected],0,1:6379>DBSIZEREDIS中存在7条数据(INTEGER) 7FLUSHALL127.0.0.1:6379>OK执行FLUSHALL命令127.0.0.1:6379>QUIT[ROOT@LOCALHOST BIN]# LL21556TOTAL30LUL2623:19CONFDRWXR-XR-X, 2ROOTROOT8927JUL00:46DUMP. RDBRW-R-R--. 1ROOTROOTXXSCSSREDIS - BENCHMARK5204342JUL06:561ROOTROOTRWXR-XR-X.JUL12REDIS - CHECK - AOFREDIS.06:561SERVERROOTL RWXRWXRWX.ROOT12JULREDIS - CHECK- RDBREDIS- SERVER06:56L RWXRWXRWX,ROOTROOT5421781JULREDIS-CLI06:56ROO1ROOTRWXR-XR-X.62212REDIS - SERVERREDIS-SENTINEL06:56L RWXRWXRWX,ROO1ROOTJULROOT 1143819106:56REDISSERVERROOTRWXR-XR-X.
优点：
●性能高：RDB持久化是通过生成一个快照文件来保存数据，因此在恢复数据时速度非常快。
●文件紧凑：RDB文件是二进制格式的数据库文件，相对于AOF文件来说，文件体积较小。
缺点：
●可能丢失数据：由于RDB是定期生成的快照文件，如果Redis意外宕机，最近一次的修改可能会丢失。
TIPS
Redis持久化默认开启为RDB持久化
AOF持久化
AOF持久化需要手动修改conf配置开启。
AOF持久化流程：
AOF日志重写启动时读取AOF日志文件恢复数据客户端写请求AOF日志文件AOF缓冲区REDIS进程
AOF持久化方案进行备份时，客户端所有请求的写命令都会被追加到AOF缓冲区中，缓冲区中的数据会根据Redis配置文件中配置的同步策略来同步到磁盘上的AOF文件中，同时当AOF的文件达到重写策略配置的阈值时，Redis会对AOF日志文件进行重写，给AOF日志文件瘦身。Redis服务重启的时候，通过加载AOF日志文件来恢复数据。
AOF配置：
AOF默认不开启，默认为appendonly no，开启则需要修改为appendonly yes
APPENDONLY YES
关闭AOF+RDB混合模式，设为no：
AOF-USE-RDB-PREAMBLEOU
AOF同步策略：
APPENDFSYNC#ALWAYSLAPPENDFSYNC EVERYSEC#APPENDFSYNC NO
appendfsync always：
○每次Redis写操作，都写入AOF日志，非常耗性能的。
appendfsync everysec
○每秒刷新一次缓冲区中的数据到AOF文件，这个Redis配置文件中默认的策略，兼容了性能和数据完整性的折中方案，这种配置，理论上丢失的数据在一秒钟左右
appendfsync no
○Redis进程不会主动的去刷新缓冲区中的数据到AOF文件中，而是直接交给操作系统去判断，这种操作也是不推荐的，丢失数据的可能性非常大。
AOF修复功能：
redis 7版本，AOF文件存储在appendonlydir文件下，base是基准文件，incr是追加数据。
JUL0APPENDONLY.AOF.1.BASE.AOFROOTROOTRW-R--R--.102:58.AOF.1.INCR.AOF0APPENDONLY.ROOTROOTRW-R--R--.1ROOT 88 JUL 27 0702:58ROOTAPPENDONLY.AOF.MANIFEST-RW-R--R--.
先存入三条数据，然后破坏incr结尾的文件内容，末尾加上baili
[ROOT@LOCALHOSTREDIS-SERVER CONF/REDIS-CONFIG.CONFBIN]#[ROOT@LOCALHOSTBIN]#REDIS-CLI -P 6379127.0.0.1:6379>SETAA AAOK127.0.0.1:6379> SET BB BBOK127.0.0.1:6379> SET CC CCOK
SET$2CC2$CC百里
重新启动报错：
[ROOT@LOCALHOST BIN]#D1N]# REDIS-CLI -P 6379CONNECTION REFUSEDREDIS AT 127.0.0.1:6379:COULDTO REDNOT CONNECTCONNECTED>NOT
使用redis-check-aof --fix appendonlydir/appendonly.aof.1.incr.aof 对AOF日志文件进行修复
REDIS-SERVER CONF/REDIS-CONFIG.CONF[ROOT@LOCALHOST BIN]#6379[ROOT@LOCALHOST BIN]#REDIS-CLI127.0.0.1:6379>GET CC(NIL)*127.0.0.1:6379> KEYSBB"
观察数据可以知道，丢失了cc-key值。这种丢失是被允许的。
AOF重写
重写其实是针对AOF存储的重复性冗余指令进行整理，比如有些key反复修改，又或者key反复修改后最终被删除，这些过程中的指令都是冗余且不需要存储的。
自动重写：
当AOF日志文件达到阈值时会触发自动重写。
重写阈值配置：
AUTO-AOF-REWRITE-PERCENTAGE100AUTO-AOF-REWRITE-64MB- SIZE- MIN
●auto-aof-rewrite-percentage 100：当AOF文件体积达到上次重写之后的体积的100%时，会触发AOF重写。
●auto-aof-rewrite-min-size 64mb：当AOF文件体积超过这个阈值时，会触发AOF重写。
当AOF文件的体积达到或超过上次重写之后的比例，并且超过了最小体积阈值时，Redis会自动触发AOF重写操作，生成一个新的AOF文件。
手动重写：bgrewriteaof
正常启动后存在三个文件：
JUL0APPENDONLY.AOF.1.BASE.AOFROOTROOTRW-R--R--.102:58.AOF.1.INCR.AOF0APPENDONLY.ROOTROOTRW-R--R--.1ROOT 88 JUL 27 0702:58ROOTAPPENDONLY.AOF.MANIFEST-RW-R--R--.
通过set命令存储三条数据，最后在修改aa数据，然后手动重写：
BIN]# REDIS-CLI[[email protected]:6379>SETAA AAOK127.0.0.1:6379> SET AA AALAA1OK127.0.0.1:6379> SET AA AA2OK127.0.0.1:6379>SET AA BAILIOK127.0.0.1:6379>BGREWRITEAOFBACKGROUNDSTARTEDONLY FILEREWRITINGAPPEND
观察结果可以得知key值aa历史轨迹已经被删除
$6SELECT$1*3$3SET$2AA$5BAILI
优点：
●数据更加可靠：AOF持久化记录了每个写命令的操作，因此在出现故障时，可以通过重新执行AOF文件来保证数据的完整性。
●可以保留写命令历史：AOF文件是一个追加日志文件，可以用于回放过去的写操作。
缺点：
●文件较大：由于记录了每个写命令，AOF文件体积通常比RDB文件要大。
●恢复速度较慢：当AOF文件较大时，Redis重启时需要重新执行整个AOF文件，恢复速度相对较慢。
混合持久化
Redis4.0版本开始支持混合持久化，因为RDB虽然加载快但是存在数据丢失，AOF数据安全但是加载缓慢。
混合持久化通过aof-use-rdb-preamble yes开启，Redis 4.0以上版本默认开启
AOF-USE-RDB-PREAMBLEYES
开启混合持久化之后：appendonlydir文件下存在一个rdb文件与一个aof文件
04:2289APPENDONLY.AOF.L.BASE.RDBROOTROOTRW-R--R--,04:221JULAPPENDONLY.AOF.1.INCR.AOFROOTRW-R--R--ROOT88 JUL 27 04:221APPENDONLY.AOF.MANIFESTROOTROOT-RW-R--R--
存入数据，然后执行bgrewriteaof重写文件。
6379BIN]#[[email protected]:6379>SETAAAAOK127.0.0.1:6379>SET AA BBOK127.0.0.1:6379>SET AA CCOK127.0.0.1:6379>SET AA BAILIOK127.0.0.1:6379>BGREWRITEAOFBACKGROUNDONLY FILEREWRITING STARTEDAPPEND
APPENDONLYDIR]#[ROOT@LOCALHOSTAPPENDONLY.AOF.2.BASE.RDBCATREDIS-VER7.0.12REDIS0010S[ROOT@LOCALHOST APPENDEREDIS-BITSODEQTUSED-MEMAOF-BASEA PO BAILIY
总结
●推荐两者均开启
●如果对数据不敏感，可以选单独用RDB
●不建议单独用AOF，因为可能会出现Bug
●如果只是做纯内存缓存，可以都不用
2.Redis缓存击穿、缓存雪崩、缓存穿透
缓存击穿、缓存雪崩和缓存穿透是我们在日常开发与手撕面试官过程中必须battle的常见问题，下面我会解释它们的含义与解决方案。
1缓存击穿（Cache Miss）
什么是缓存击穿？
缓存击穿是指在高并发访问下，一个热点数据失效时，大量请求会直接绕过缓存，直接查询数据库，导致数据库压力剧增。
通常情况下，缓存是为了减轻数据库的负载，提高读取性能而设置的。当某个特定的缓存键（key）失效后，在下一次请求该缓存时，由于缓存中没有对应的数据，因此会去数据库中查询，这就是缓存击穿。
解决方案：
●合理的过期时间：设置热点数据永不过期，或者设置较长的过期时间，以免频繁失效。
●使用互斥锁：保证同一时间只有一个线程来查询数据库，其他线程等待查询结果。
2缓存雪崩（Cache Avalanche）
什么是缓存雪崩？
缓存雪崩是指在大规模缓存失效或者缓存宕机的情况下，大量请求同时涌入数据库，导致数据库负载过大甚至崩溃的情况。
正常情况下，缓存中的数据会根据过期时间进行更新，当大量数据同时失效时，下一次请求就会直接访问数据库，给数据库带来巨大压力。
解决方案：
●合理的过期时间：为缓存的过期时间引入随机值，分散缓存过期时间，避免大规模同时失效。或者是粗暴的设置热点数据永不过期
●多级缓存：使用多级缓存架构，如本地缓存 + 分布式缓存，提高系统的容错能力。
●使用互斥锁：保证同一时间只有一个线程来查询数据库，其他线程等待查询结果。
●高可用架构：使用Redis主从复制或者集群来增加缓存的可用性，避免单点故障导致整个系统无法使用。
3缓存穿透（Cache Penetration）
什么是缓存穿透？
缓存穿透是指恶意请求查询一个不存在于缓存和数据库中的数据，导致每次请求都直接访问数据库，从而增加数据库的负载。
攻击者可以通过故意构造不存在的 Key 来进行缓存穿透攻击。
解决方案：
●缓存空对象：对于查询结果为空的情况，也将其缓存起来，但使用较短的过期时间，防止攻击者利用同样的 key 进行频繁攻击。
●参数校验：在接收到请求之前进行参数校验，判断请求参数是否合法。
●布隆过滤器：判断请求的参数是否存在于缓存或数据库中。
3.什么是Redis哨兵机制
为什么需要哨兵机制？
Redis的主从复制主要用于实现数据的冗余备份和读分担，并不是为了提供高可用性。因此在系统高可用方面，单纯的主从架构无法很好的保证整个系统高可用。比如说：
MASTERMYSQLSLAVESLAVE主从复制:多副本
●需要人工介入：需要人工介入进行主节点切换。当主节点发生故障时，主从复制无法自动进行主节点的切换。需要管理员手动干预，修改配置将一个从节点提升为新的主节点。这增加了人工操作的复杂性和潜在的延迟。
●主节点写能力有限：主节点的写能力受限于单个节点。在主从复制中，所有写操作都必须发送给主节点处理，然后再同步到从节点。这导致主节点成为写入瓶颈，其写能力受限于单个节点的硬件和性能。如果负载过大，主节点的响应时间可能会增加，影响整体性能。
●单机节点存储能力有限：存储能力受限于主节点的容量。在主从复制中，所有数据都存储在主节点上，从节点仅用于提供读服务。这限制了整个系统的存储能力，因为主节点的存储容量有限。如果数据量增长过快或存储需求增加，主节点的存储容量可能会成为瓶颈。
因此通常是使用Redis哨兵机制或Redis集群模式来提高整个系统的可用性、扩展性和负载均衡能力。
哨兵机制(sentinel)的原理
Redis哨兵机制是通过在独立的哨兵节点上运行特定的哨兵进程来实现的。这些哨兵进程监控主从节点的状态，并在发现故障时自动完成故障发现和转移，并通知应用方，实现高可用性。
以下是哨兵机制的工作原理：
哨兵集群SENTINELMASTER监控MYSQLSENTINELSENTINELSLAVESLAVE监控REDIS哨兵高可用架构
a哨兵选举：
在启动时，每个哨兵节点会执行选举过程，其中一个哨兵节点被选为领导者（leader），负责协调其他哨兵节点。
ⅰ选举过程：
●每个在线的哨兵节点都可以成为领导者，每个哨兵节点会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者；
●当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
●如果哨兵发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举。
b监控主从节点：
哨兵节点通过发送命令周期性地检查主从节点的健康状态，包括主节点是否在线、从节点是否同步等。如果哨兵节点发现主节点不可用，它会触发一次故障转移。
c故障转移：
一旦主节点被判定为不可用，哨兵节点会执行故障转移操作。它会从当前的从节点中选出一个新的主节点，并将其他从节点切换到新的主节点。这样，系统可以继续提供服务而无需人工介入。
ⅰ故障转移过程：
○由Sentinel节点定期监控发现主节点是否出现了故障： sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了。
○确认主节点：
■过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
■选择从节点优先级最高的
■选择复制偏移量最大，此指复制最完整的从节点
当主节点出现故障， 由领导者负责处理主节点的故障转移。
d客户端重定向：
哨兵节点会通知客户端新的主节点的位置，使其能够与新的主节点建立连接并发送请求。这确保了客户端可以无缝切换到新的主节点，继续进行操作。
此外，哨兵节点还负责监控从节点的状态。如果从节点出现故障，哨兵节点可以将其下线，并在从节点恢复正常后重新将其加入集群。
客观下线
当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线。
总结
redis哨兵的作用:
●监控主数据库和从数据库是否正常运行。
●主数据库出现故障时，可以自动将从数据库转换为主数据库，实现自动切换。
4.说一说Redis的过期策略和内存淘汰策略
allkeys-random（全局随机删除）noeviction（不淘汰策略）allkeys-lru（全局最近最少使用）volatile-lru（最近最少使用）volatile-random（随机删除）volatile-ttl（根据过期时间优先）Redis的内存淘汰策略定期过期策略（Active expiration）惰性过期策略（Lazy expiration）Redis的过期策略Redis的过期策略和内存淘汰策略Redis的过期策略
a惰性删除（Lazy expiration）
●当客户端尝试访问某个键时，Redis会先检查该键是否设置了过期时间，并判断是否过期。
●如果键已过期，则Redis会立即将其删除。这就是惰性删除策略。
该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
b定期删除（Active expiration）
●Redis会每隔一段时间（默认100毫秒）随机检查一部分设置了过期时间的键。
●定期过期策略通过使用循环遍历方式，逐个检查键是否过期，并删除已过期的键值对。
通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果
Redis中同时使用了惰性过期和定期过期两种过期策略。
●假设Redis当前存放20万个key，并且都设置了过期时间，如果你每隔100ms就去检查这全部的key，CPU负载会特别高，最后可能会挂掉。
●因此redis采取的是定期过期，每隔100ms就随机抽取一定数量的key来检查和删除的。
●但是呢，最后可能会有很多已经过期的key没被删除。这时候，redis采用惰性删除。在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间并且已经过期了，此时就会删除。
需要注意如果定期删除漏掉了很多过期的key，然后也没走惰性删除。就会有很多过期key积在内存中，可能会导致内存溢出，或者是业务量太大，内存不够用然后溢出了，为了应对这个问题，Redis引入了内存淘汰策略进行优化。
Redis的内存淘汰策略
内存淘汰策略允许Redis在内存资源紧张时，根据一定的策略主动删除一些键值对，以释放内存空间并保持系统的稳定性。
anoeviction（不淘汰策略）
当内存不足以容纳新写入数据时，Redis 将新写入的命令返回错误。这个策略确保数据的完整性，但会导致写入操作失败。
bvolatile-lru（最近最少使用）
从设置了过期时间的键中选择最少使用的键进行删除。该策略优先删除最久未被访问的键，保留最常用的键。
cvolatile-ttl（根据过期时间优先）
从设置了过期时间的键中选择剩余时间最短的键进行删除。该策略优先删除剩余时间较短的键，以尽量保留剩余时间更长的键。
dvolatile-random（随机删除）
从设置了过期时间的键中随机选择一个键进行删除。
eallkeys-lru（全局最近最少使用）
从所有键中选择最少使用的键进行删除。无论键是否设置了过期时间，都将参与淘汰。
fallkeys-random（全局随机删除）
从所有键中随机选择一个键进行删除。