作业（六）作业

1、RDB和AOF的优缺点

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

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

RDB可以最大化Redis的性能，父进程在保存 RDB文件时唯一要做的就是fork出一个子进程，然后
这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘工/0操作。
RDB在大量数据,比如几个G的数据，恢复的速度比AOF的快

RDB 模式缺点
不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据
如果你需要尽量避免在服务器故障时丢失数据，那么RDB不适合你。虽然Redis允许你设置不同的
保存点（save point）来控制保存RDB文件的频率，但是，因为ROB文件需要保存整个数据集的状
态，所以它并不是一个轻松的操作。因此你可能会至少5分钟才保存一次RDB文件。在这种情况
下，一旦发生故障停机，你就可能会丢失好几分钟的数据。
当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或
者秒，取决于磁盘IO性能
在数据集比较庞大时，fork()可能会非常耗时，造成服务器在一定时间内停止处理客户端﹔如果数
据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。
虽然 AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何
损失。

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

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

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

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

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

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

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

根据fsync策略不同,AOF速度可能会慢于RDB bug 出现的可能性更多

2、master和slave同步过程

1、slave server启动连接到master server之后，salve server主动发送SYNC命令给master server。

2、master server接受SYNC命令之后，判断，是否有正在进行内存快照的子进程，如果有，则等待其结束，否则，fork一个子进程，子进程把内存数据保存为文件，并发送给slave server。

3、master server子进程进程做数据快照时，父进程可以继续接收client端请求写数据，此时，父进程把新写入的数据放到待发送缓存队列中。

4、slave server 接收内存快照文件之后，清空内存数据，根据接收的快照文件，重建内存表数据结构。

5、master server把快照文件发送完毕之后，发送缓存队列中保存的子进程快照期间改变的数据给slave server，slave server做相同处理，保存数据一致性。

6、master server 后续接收的数据，都会通过步骤1建立的连接，把数据发送到slave server

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

实现哨兵的前提是已经部署主从
Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本。哨兵(Sentinel) 是一个分布式系统，你可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个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) 虽然有一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)，哨兵(sentinel) 的一些设计思路和zookeeper非常类似。

       Sentinel集群之间会互相通信，沟通交流redis节点的状态，做出相应的判断并进行处理，这里的主观下线状态和客观下线状态是比较重要的状态，它们决定了是否进行故障转移，可以 通过订阅指定的频道信息，当服务器出现故障得时候通知管理员，客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器，你不可以使用 PUBLISH 命令向这个服务器发送信息，但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。

4、redis cluster集群创建和使用

准备6台服务器，分别是三组master/slave
#集群节点
10.0.0.8
10.0.0.18
10.0.0.28
10.0.0.38
10.0.0.48
10.0.0.58
#预留服务器扩展使用
10.0.0.68
10.0.0.78

所有节点安装redis
[root@centos8 ~]# yum -y install redis
[root@centos8 ~]#sed -i.bak -e ‘s/bind 127.0.0.1/bind 0.0.0.0/’ -e ‘/masterauth/a masterauth 123456’ -e ‘/# requirepass/a requirepass 123456’ -e ‘/# cluster-enabled yes/a cluster-enabled yes’ -e ‘/# cluster-config-file nodes-6379.conf/a cluster-config-file nodes-6379.conf’ -e ‘/cluster-requirefullcoverage yes/c cluster-require-full-coverage no’ /etc/redis.conf
[root@centos8 ~]#systemctl enable --now redis

执行meet 实现相互通信
#在任一节点上和其它所有节点进行meet通信
[root@centos8 ~]#redis-cli -h 10.0.0.8 -a 123456 --no-auth-warning cluster meet 10.0.0.18 6379
[root@centos8 ~]#redis-cli -h 10.0.0.8 -a 123456 --no-auth-warning cluster meet 10.0.0.28 6379
[root@centos8 ~]#redis-cli -h 10.0.0.8 -a 123456 --no-auth-warning cluster meet 10.0.0.38 6379
[root@centos8 ~]#redis-cli -h 10.0.0.8 -a 123456 --no-auth-warning cluster meet 10.0.0.48 6379
[root@centos8 ~]#redis-cli -h 10.0.0.8 -a 123456 --no-auth-warning cluster meet 10.0.0.58 6379

为各个master 节点指派槽位范围
指定各个节点的主从关系
验证 redis cluster 访问