Redis持久化与集群机制-优快云博客

本文链接：https://blog.youkuaiyun.com/unicorn_mitnick/article/details/123854818

docs/Redis/Redis面试题带答案（2021年Redis面试题及答案大汇总）.md · 鹏磊/NewDevBooks - Gitee.com

主从，哨兵，Cluster

概述

Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；
也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。

一：RDB和AOF

RDB持久化：是一种快照形式,对数据在某时某点的一种完整备份，Redis会单独fork一个子进程来持久化,来记录到临时文件(保证数据完整性和安全性)，结束后在dump到磁盘上替换上次持久化的文件)Redis RDB，MySQL Dump都是这种。写时复制技术。

save：Reids save命令执行一个同步保存操作，将当前Redis实例的所有数据快照(snapshort)已RDB文件的方式保存到磁盘

bgsave：bgsave执行后，会立刻返回OK，Redis 会fork一个子进程，原来的redis主进程继续执行后续操作，新fork的子进程负责将数据保存到磁盘，然后退出

区别：

save同步阻塞主进程，只有等save完后成，才能进行新操作
basave 是fork的子进程，非阻塞，等执行完后会通知主进程，然后关闭子进程

AOF(append only file)持久化：默认不开启,原理是将Reids的操作日志以追加的方式写入文件,只记录写操作,不记录读操作。Redis服务启动之初,会读取该文件重新构建数据(RDB和AOF都开启,首选恢复AOF数据)

两种方式都开启,数据恢复redis优先选用AOF

二：RDB

1.RDB优点

1.适合于大规模的数据恢复，并且还原速度快(redis服务启动后会找到dump.rdb自动恢复)
2.生成多个数据文件，适合冷备份
3.fork子进程处理，对外提供的读写影响小
4.重启和恢复redis进程，更快速

2.RDB缺点

故障时，比AOF丢失较多数据(一般每隔5分钟生成一次),RDB间隔时间长，生成RDB文件太大，Fork的时候,内存中的数据被克隆了一份,占用2倍内存,影响性能，最后一次持久化操作,服务挂了,数据会丢失。

# 生成的文件名称
dbfilename dump.rdb
# 路径
dri /var/lib/redis
# yes表示Redis无法写入硬盘了,关闭Redis的写操作
stop-writes-on-bgsave-error yes
# yes表示持久化文件压缩 
rdbcompression yes
# yes表示持久化之前检测完整性,会增加大约10%性能消耗
rdbchecksum yes


save 900 1
save 300 10
save 60  10000

save 900 1 表示在 900 秒内，至少更新了 1 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。
save 300 10 表示在 300 秒内，至少更新了 10 条数据，Redis 自动触 BGSAVE 命令，将数据保存到硬盘。
save 60 10000 表示 60 秒内，至少更新了 10000 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。

三：AOF

1.AOF优点

该机制有3中同步策略，即每秒同步、每修改同步和不同步
每秒同步：是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。
每修改同步: 我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。
不同步：Redis不主动同步,交给操作系统决定,这种方式在效率上是最低的
重写机制：当AOF文件大于base_size+base_sizex100%,保证文件不会太大。

# no默认关闭
appendonly no
# 文件名称
appendfilename "appendonly.aof"
# 备份模式
# appendfsync always
appendfsync everysec
# appendfsync no
Always：服务器每写入一个命令，就调用一次 fsync 函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据，但是其执行速度较慢；
Everysec（默认）：服务器每一秒调用一次 fsync 函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据，通常都使用它作为 AOF 配置策略；
No：服务器不主动调用 fsync 函数，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的，所以这种策略，不确定性较大，不安全。

2.AOF缺点

相同数据，AOF文件大于RDB，AOF恢复速度比RDB慢

Redis 的 List 集合中,并将超出集合部分从数据库获取。使用 LPUSH latest.comments<ID>命令,向 list 集合中插入数据,插入完成后再用 LTRIM latest.comments 0 5000 命令使其永远只保存最近 5000 个

Redis应用场景

1. 显示最新的项目列表
2.按照用户投票和时间排序
3.过期项目处理
4.计数
5.缓存（Redis能够替代memcached，让你的缓存从只能存储数据变得能够更新数据，因此你不再需要每次都重新生成数据了）

四：Mysql有2000w数据，redis有20w数据，如何保证redis里都是热点数据?

1.超过最大内存的6中淘汰策略

noeviction: 不删除策略。当达到最大内存限制时, 如果需要使用更多内存,则直接返回错误信息。（redis默认淘汰策略）
allkeys-lru: 在所有key中优先删除最近最少使用(less recently used ,LRU) 的 key。
allkeys-random: 在所有key中随机删除一部分 key。
volatile-lru: 在设置了超时时间（expire ）的key中优先删除最近最少使用(less recently used ,LRU) 的 key。
volatile-random: 在设置了超时时间（expire）的key中随机删除一部分 key。
volatile-ttl: 在设置了超时时间（expire ）的key中优先删除剩余时间(time to live,TTL) 短的key。

使用 allkeys-lru 淘汰策略来解决

2.过期键的删除策略

1、定时删除:在设置键的过期时间的同时，创建一个定时器timer)、让定时器在键的过期时间来临时，立即执行对键的删除操作。

2、惰性删除:放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键;如果没有过期，就返回该键。

3、定期删除:每隔一段时间程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定。

五：redis的同步机制

同步机制分为全同步(slave启动的初始化)，部分同步(redis运行中的修改同步)

1.全同步

1）在slave启动时，会向master发送一条SYNC指令。

2）master收到这条指令后，会启动一个备份进程将所有数据写到rdb文件中去。

3）更新master的状态（备份是否成功、备份时间等），然后将rdb文件内容发送给等待中的slave。

注意，master并不会立即将rdb内容发送给slave。而是为每个等待中的slave注册写事件，当slave对应的socket可以发送数据时，再讲rdb内容发送给slave。

2.部分同步

当Redis的master/slave服务启动后，首先进行全同步。之后，所有的写操作都在master上，而所有的读操作都在slave上。因此写操作需要及时同步到所有的slave上，这种同步就是部分同步。
1）master收到一个操作，然后判断是否需要同步到salve。
2）如果需要同步，则将操作记录到aof文件中。
3）遍历所有的salve，将操作的指令和参数写入到savle的回复缓存中。
4）一旦slave对应的socket发送缓存中有空间写入数据，即将数据通过socket发出去。