【肝货】Redis相关操作以及原理

持久化

操作

RDB（Redis数据备份文件）:
命令：save（主进程执行RDB，阻塞所有命令）、
bgsave（子进程执行命令，避免主进程受影响）

redis.conf文件配置：save 900 1（900秒内一个key被修改就执行bgsave）、
rdbcompression yes（是否压缩rdb文件）、
dbfilename dump.rdb（命名RDB文件）、
dir ./（文件保存目录）

AOF（追加文件）
命令：bgrewriteaof （让AOF执行重写功能，AOF会对同一个key有多次读写操作，但只要最后一次的操作才有意义）

redis.conf文件配置：appendonly yes（是否开启aof,默认是no）、
appendfilename “appendonly.aof”（aof的文件名称）。
appendfsync always（每执行一次就记录到aof文件）
appendfsync everysec（写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案）
appendfsync no（写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘）

持久化原理

RDB的bgsave流程：
1.Fork主进程得到一个子进程，共享内存空间
2.子进程读取内存数据并写入新的RDB文件
3.用新的RDB文件替换旧的RDB文件
4.（这种方式Redis使用了copy-on-write技术，主进程的写操作都是在数据副本上进行）

主从集群

操作

1.创建目录
进入/tmp，创建三个文件夹：7001,7002,7003
2.修改redis-6.2.4/redis.conf文件，将其中的持久化改为默认的RDB模式，AOF保持关闭。
3.拷贝配置文件到每个实例目录
将redis-6.2.4/redis.conf文件拷贝到三个目录中（在/tmp目录下执行）
4.修改每个实例的端口、工作目录
修改每个文件夹内的配置文件，将端口分别改为7001、7002、7003，将rdb文件保存的位置都修改为自己所在的目录（在/tmp目录下执行）
5.修改每个实例的声明ip
/redis.conf配置文件里：replica-announce-ip 192.168.150.101
6.开启主从关系
7001为主，7002、7003为从，则在7002、7003上执行slaveof ip 7001（意思做你7001的奴隶），5.0后replicaof和slaveof效果一样。

主从同步原理

主从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer（repl_baklog文件），待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放。
注意：redis的主节点创建和维护一个环形缓冲复制队列（即repl_backlog），从节点部分同步（增量同步）的数据均来自于repl_backlog。
主从同步第一次是全量同步，但如果slave重启后同步，则是增量同步。
通过repl_baklog文件，大小有上限，写满后会覆盖最早的数据。如果slave宕机时间过长，导致尚未备份的数据被覆盖，则只能全量同步。

如何判断全量同步还是增量同步
通过repIid判断主从是否一致。第一次从节点还未继承master的replid，所以不一致则无法进行增量同步。
Replication ID: 简称repIid，数据集的标记，id一致则说明是统一数据集。每一个master都有唯一的replid，slave会继承master的replid。Id一致则说明不是第一次同步。
Offset：偏移量，随着记录在repl_baklog中的数据增多而增大。Salve完成同步也会记录自己的offset，当slave的offset小于master的offset，则需要更新。

哨兵集群

操作

1.创建目录进入/tmp，创建三个文件夹：s1,s2,s3 2. 在s1目录创建一个sentinel.conf文件，添加以下内容:port 27001（是当前sentinel实例的端口）
sentinel announce-ip 192. 168.150.101
sentinel monitor mymaster 192. 168.150.101 7001 2（指定主节点信息）
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000 dir "/tmp/s1"
dir:工作目录， mymaster：主节点名称，自定义随意写192. 168.150.101 7001 2：主节点的ip和端口号
2：选举master的quorum值（如果一共三台，一半以上就是2）
3. 将s1的sentinel.conf文件拷贝到s2、s3两个目录中（在/tmp目录下执行）逐个拷贝命令：cp s1/sentinel.conf s2cp s1/sentinel.conf s3 组合管理，一键拷贝命令：echo s2 s3 |xargs -t -n 1 cp s1/sentinel. conf
4.修改s2、s3两个文件夹内的配置文件，将端口分别改为27002、27003：
sed -i -e ’ s/27001/27002/g’ -e ’ s/s1/s2/ g ’ s2/sentinel.confsed -i -e ’ s/27001/27003/g’ -e ’ s/s1/s3/ g ’ s3/sentinel.conf
5.启动三个redis实例，启动命令（在/tmp目录下执行）
redis-sentinel s1/sentinel. conf
redis-sentinel s2/sentinel. conf
redis-sentinel s3/sentinel. conf

启动成功后，sentinel则开始监控集群。(视频来源：https://www.bilibili.com/video/BV1LQ4y127n4?p=152 15分钟起)

原理

如何选举新的master
一旦发现master故障，sentinel需要在salve中选择一个作为新的master
①首先会判断slave节点与master节点断开时间长短，如果超过指定值则会排除该slave节点
②然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
③如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
④最后判断slave节点的运行id大小，越小优先级越高。（随意判断）

如何实现故障转移
1.哨兵给备选的slave节点发送slaveof no one命令，让该节点成为master。
2.哨兵给所有slave发送slaveof 192.168.150.101 7002命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
3.哨兵将故障节点标记为slave，当故障恢复后会自动成为新的master的从节点。

作用：
1.监控
2.故障转移
3.通知

哨兵如何判断一个redis实例是否健康？
1.每隔一秒发送一次ping命令，超过一点时间没有响应则认为是主管下线。
2.大多数哨兵sentinel都认为实例主管下线，则判定为服务下线。