作业六

1、RDB和AOF的优缺点

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

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

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

RDB缺点：（1）不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据。

（2）当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间可能是毫秒或者秒，取决于IO性能

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

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

（3）Redis可以在AOF文件体积变得过大时，自动的在后台对AOF进行重写，重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。

（4）AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。

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

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

（3）bug出现的可能性更多

2、master和slave同步过程

准备三台主机C81（master:10.0.0.18）、C82（slave1:10.0.0.28）、 C83(slave2:10.0.0.38)

先在这三台主机上安装redis，用脚本安装，脚本过程如下：

在C81master上设置key1

在C82 slave1上执行，登录

在C83 slave2上执行，登录

在C81master主机上查看连接状况，显示两个slave，主从连接成功

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

准备三台主机在上面实现哨兵机制（C81：master:10.0.0.18）

(C82：slave1：10.0.0.28) （C83：slave2：10.0.0.38）

在三台机器上用yum下载redis，并在上面完成配置

所有主从配置用非交互式执行

在所有从节点上执行

所有主从节点重启redis

配置slave1

配置slave2

查看master状态是否主从连接成功，显示slave:2，两个slaveIP则连接成功

三个主从服务器的哨兵服务器的配置都如下，要确保每个哨兵主机myid不同

启动三台哨兵服务器，执行每台主机是执行相同的命令

所有主机验证哨兵端口是否打开：显示26379端口则已经启动哨兵服务

在master主机上查看sentinel 连接状态，两个slave，三个sentinel服务器

测试哨兵服务是否配置成功，用kill除掉master主机的redis服务，可以在slave1主机上看到哨兵把slave1提升为新的主节点，则哨兵服务配置成功

4、redis cluster 集群创建和使用

redis cluster集群创建和使用

在哨兵sentinel机制中，可以解决redis高可用问题，即当master故障后可以自动将slave提升master，从而可以保证redis服务的正常使用，但是无法解决redis单机写入的瓶颈问题，即单机redis写入性能受限于单机的内存大小、并发数量、网卡速率等因素。

Redis Cluster特点如下：

所有Redis节点使用(PING机制)互联

集群中某个节点的是否失效，是由整个集群中超过半数的节点监测都失效，才能算真正的失效

客户端不需要proxy即可直接连接redis，应用程序中需要配置有全部的redis服务器IP

redis cluster把所有的redis node 平均映射到 0-16383个槽位(slot)上，读写需要到指定的redis node上进行操作，因此有多少个redis node相当于redis 并发扩展了多少倍，每个redis node 承 担16384/N个槽位

Redis cluster预先分配16384个(slot)槽位，当需要在redis集群中写入一个key -value的时候，会使用CRC16(key) mod 16384之后的值，决定将key写入值哪一个槽位从而决定写入哪一个Redis节点上，从而有效解决单机瓶颈。

redis-5.0.3-1版本部署

使用主机为六台

（1）在各个主机下执行下列命令修改redis配置

sed -i ‘s/bind 127.*/bind 0.0.0.0/’ /etc/redis.conf

sed -i ‘s/masterauth.*/masterauth 441424/’ /etc/redis.conf #此处设置redis主节点密码

sed -i ‘s/# requirepass.*/requirepass 441424/’ /etc/redis.conf #设置redis密码

sed -i ‘s/# cluster-enabled.*/cluster-enabled yes/’ /etc/redis.conf #开启集群

sed -i ‘s/# cluster-config-file.*/cluster-config-file nodes-6379.conf/’ /etc/redis.conf #取消此行注释,此文件由 redis cluster 集群自动创建和维护

sed -i ‘s/# cluster-require.*/cluster-require-full-coverage no/’ /etc/redis.conf #默认值为yes,设为no可以防止一个节点不可用导致整个cluster不可用

systemctl restart redis

（2）查看redis进程就能看到集群状态

（3）建立集群前先确认所有数据库书否为空

redis-cli -a 441424 flushall #清理所有数据库

（4）建立集群

redis-cli -a 441424 --cluster create 10.0.0.18:6379 10.0.0.28:6379 10.0.0.38:6379 10.0.0.48:6379 10.0.0.58:6379 10.0.0.68:6379 --cluster-replicas 1

（5）输入yes自动创建集群

（6）槽位分配完成

（7）验证集群情况

（8）查看各集群节点对应关系

（10） 验证集群写入key

redis-cli -a 441424 --no-auth-warning set key1 values1

（11）集群服务会提示到135节点写入

（12）135节点写入即可

（13）或者添加"-c"选项开启集群模式写入