2020.10.26 Redis相关作业

1、RDB和AOF的优缺点

RDB的优点

RDB快照保存了某个时间点的数据，可以通过脚本执行redis指令bgsave（非阻塞，后台执行）或者save（会阻塞写操作，前台执行，不推荐）命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本，很适合备份，并且文件格式也支持有不少第三方工具可以进行后续的数据分析。比如：

可以在24小时内，每小时备份一次RDB文件，并且在每个月的第一天，也备份一个RDB文件。这样的话即使遇上问题，也可以随时将数据集还原到不同的版本。

RDB可以最大化Redis性能，父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘I/O操作。

RDB在大量数据，比如几个G的数据，恢复的速度比AOF的快

RDB的缺点

不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据

虽然Redis允许设置不同的保存点来控制保存RDB文件的频率，但是因为RDB文件需要保存整个数据集的状态，所以他并不是一个轻松的操作。因此可能会至少5分钟才保存一次RDB文件。在这种情况下，服务器一旦宕机，就会丢失好几分钟的数据。

当数据量非常大的时候，从父进程fork子进程进行保存值RDB文件需要一点时间，可能是毫秒或秒，取决于磁盘I/O性能

在数据量比较庞大是，fork可能会非常耗时，造成服务器在一定时间内停止处理客户端过来的请求，如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。虽然AOF重写也需要fork，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何损失

AOF的优点

数据安全性相对较高，根据所使用的fsync策略（fsync是同步内存中redis所有已经修改的文件到存储设备），默认是appendfsync everysec，即每秒执行一次，在这种配置下，Redis仍然可以保持良好的性能，并且就算发生故障停机，也最多只会损失一秒钟的数据（fsync会在后台线程执行，所以主线程可以继续努力地处理命令请求）

由于该机制对日志文件的写入操作采用的追加模式，以你在写入过程中不需要seek，即使出现宕机现象，也不会破坏日志文件中已经存在的内容，然而如果本次操作只是写了一半数据就出现了系统崩溃问题，不用担心，在redis下一次启动之前，可以通过redis-check-aof工具来解决数据一致性的问题

redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写，重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合，整个重写操作是绝对安全的，因为redis在创建新AOF文件的过程中，追加模式不断的将修改数据追加到现有的AOF文件里面，即使重写过程中发生停机，现有的AOF文件也不会丢失。而一旦新AOF文件创建完毕，redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件产生追加操作

AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文件完成数据的重建

AOF文件有序保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松。导出AOF文件也非常简单，比如，不小心执行了flushall命令，但只要AOF文件未被重写，那么只要停止服务器，移除AOF文件末尾的flushall命令，并重启redis，就可以将数据集恢复到flushall执行之前的状态

AOF的缺点

即使有些操作是重复的也会全部记录，AOF的文件大小要大于RDB格式的文件

AOF在恢复大数据集时的速度比RDB的恢复速度要慢

根据fsync策略不同，AOF速度可能会慢于RDB

bug出现的可能性更多

2、master和slave同步过程

1、从节点主动向主节点发送同步请求

2、主节点接收到从的消息后发送自己的runid和offset发送给从节点

3、从节点保存主节点发送过来的runid和offset

4、主节点后台执行RDB持久化，并将新写入的数据写入到缓冲区中

5、主节点将RDB文件发送到从节点

6、主节点在把RDB文件发送到从节点后，把buffer中的数据以redis协议格式发送到从节点

7、从节点清空自己旧的数据

8、从节点把主节点推送过来的RDB文件中的数据载入内存，再加载所有缓冲区中的内容完成全量同步

9、全量同步完成后，如从节点需要继续同步增量数据的话，会先将自己的offset位置发送给主节点，主节点在收到后会根据从节点的offset，将从节点offset位置之后的数据发送回从节点，同时也将在缓冲区的数据也发送给从节点

3、哨兵的使用和实现机制

Sentinel进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，此功能在redis2.6+的版本已引用，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本

哨兵(Sentinel)是一个分布式系统，可以在一个架构中运行多个哨兵(sentinel)进程，这些进程使用流言协议(gossip protocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(AgreementProtocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master

每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master，Slave定时发送消息，以确认对方是否"活”"着，如果发现对方在指定配置时间(此项可配置)内未得到回应，则暂时认为对方已离线，也就是所谓的”主观认为宕机”(主观:是每个成员都具有的独自的而且可能相同也可能不同的意识)，英文名称:Subjective Down，简称SDOWN

有主观宕机，对应的有客观宕机。当"哨兵群"中的多数Sentinel进程在对Master主服务器做出SDOWN的判断，并且通过SENTINEL is-master-down-by-addr命令互相交流之后，得出的Master Server下线判断，这种方式就是"客观宕机"(客观:是不依赖于某种意识而已经实际存在的一切事物)，英文名称是:Objectively Down，简称ODOWN

通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移(failover)

Sentinel机制可以解决master和slave角色的自动切换问题，但单个Master的性能瓶颈问题无法解决,类似于MySQL中的MHA功能

Redis Sentinel中的Sentinel节点个数应该为大于等于3且最好为奇数

客户端初始化时连接的是Sentinel节点集合，不再是具体的Redis节点，但Sentinel只是配置中心不是代理。

Redis Sentinel节点与普通redis没有区别,要实现读写分离依赖于客户端程序

redis 3.0之前版本中,生产环境一般使用哨兵模式,但3.0后推出redis cluster功能后,可以支持更大规模的生产环境

#主节点redis配置
bind 0.0.0.0
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize no
supervised no
pidfile /var/run/redis_6379.pid
loglevel notice
logfile /var/log/redis/redis.log
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var/lib/redis
masterauth 123456
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
replica-priority 100
requirepass 123456
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
stream-node-max-bytes 4096
stream-node-max-entries 100
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
dynamic-hz yes
aof-rewrite-incremental-fsync yes
rdb-save-incremental-fsync yes

#从节点redis配置
bind 0.0.0.0
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize no
supervised no
pidfile /var/run/redis_6379.pid
loglevel notice
logfile /var/log/redis/redis.log
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var/lib/redis
replicaof 10.0.0.8