Redis02（持久化、主从复制、薪火相传、哨兵、集群）

1、redis持久化的方式

RDB: 把某段时间内的数据进行保存，生成一个快照。
AOF: 把每次的修改指令 记录到一个日志文件中。

1.1 rdb:

在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

1.原理
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方 式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

2.RDB触发
2.1.可以在配置文件中设置 默认的三种：900秒修改1次 |300秒修改10次| 60秒修改10000次都能触发快照

保存的地址为运行service-service的文件夹下 dump.rdb
2.2.使用flushall命令来触发，但是他保存的快照内容是空的。
2.3.服务关闭也会触发RDB.

3、rdb优点
数据恢复速度快。
对于一些数据完整性要求不高，可以采用该持久化方式
缺点：
在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

1.2 AOF

原理
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
默认redis没有开启aof。如果修改成yes，则启用aof

aof的触发条件:

Always: 总是触发 没执行一条修改语句都会触发。
Everysec: 每秒触发一次 会丢失最后一秒的数据。
No: 不触发 性能就和rdb一样。

如果aof被开启了，那么redis服务再启动时先加载aof的文件。因为aof的数据比较完整。

如果aof文件被破坏 那么可以使用命令修复aof文件，但是最后的部分数据会丢失

redis-check-aop --fix 文件名

优点:
每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
不同步：appendfsync no 从不同步
劣势：
相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

2、Redis 架构模式

主从模式（redis2.8版本之前的模式）、哨兵sentinel模式（redis2.8及之后的模式）、redis cluster模式（redis3.0版本之后）

2.1 什么是缓存穿透 如何避免？
1.缓存穿透: 大量查询缓存中不存在的key,数据库中也不存在的key时。
2.如何避免:
1.再缓存中存放一个Null的对象，并且设置较短的时间。
2.使用bloomfilter，相当有一个大的bitMap对象，里面存放了所有的key值。

2.2 缓存雪崩：什么是缓存雪崩**？何如避免**
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给后端系统带来很大压力。导致系统崩溃。

1.在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
2：搭建集群
3：不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀

==========================================

3、配置主从复制、薪火相传、哨兵、集群

shutdown  #关掉当前机器
quit #退出
slaveof no one #设置自己为主机，
info replication #查询当前redis信息
slaveof 127.0.0.1 -6379 #将当前服务器配置成6379的从机
redis-service /redis-config文件目录 #启动服务
redis-cli -p 6379  #连接6379端口的redis
redis-sentinel /serntinel.conf哨兵配置文件地址 #启动哨兵检测

3.1 主从复制（读写分离）

配从不配主

为了搭建方便 就再一个虚拟机测试。
开启三个redis， 只要他们的配置文件内容不同。

详细步骤：
①拷贝多个redis.conf文件
②开启daemonize yes 后台运行

③port指定端口 端口号

④Pid文件名字 redis启动后进程号所放的位置

⑤Log文件名字 redis日志产生的位置

⑥Dump.rdb名字 RDB持久化的内容所保存的位置

配置完成启动三个redis

连接三个端口，查看各自主从关系信息，三个都为主机初始状态
配置6380 和6381 的主节点为6379

slaveof 127.0.0.1 6379

主节点主要负责写的功能：
从节点只能读不能写。

如果主节点挂了。 思考: 从节点会上位还是等待老大回来。
等着老大回来。

3.2 薪火相传

三个redis主机

配置薪火相传80的主机是79，81的主机是80

slaveof 127.0.0.1 6379

仍然是只有6379主机能够读写，80、81只能读

这种集群都能写吗?
只有最大的老大能写！

如果最大的老大挂了，二老大能不能？
默认还是不能。

手动设置二老大为大佬大。

薪火相传 也有弊端 需要手动维护老大。
Slaveof no one

3.3 哨兵

配置哨兵的配置文件，哨兵监察6379，如果他挂了，则从从机当中选举一个，只要有一票就能设置成主机

`
在redis命令文件夹下，执行启动哨兵的命令

redis-sentinel /root/redisjiqun/sentinel.conf

将6379主机挂掉，哨兵选择6380当主机

3.4 搭建redis集群（三主三从）

哈希槽说明： a—>crc16–97%16384
Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。
当你往Redis Cluster中加入一个Key时，会根据crc16(key) mod 16384计算这个key应该分布到哪个hash slot中，一个hash slot中会有很多key和value。你可以理解成表的分区，使用单节点时的redis时只有一个表，所有的key都放在这个表里；改用Redis Cluster以后会自动为你生成16384个分区表，你insert数据时会根据上面的简单算法来决定你的key应该存在哪个分区，每个分区里有很多key。
搭建集群：
将redis文件夹下拷贝redis.conf，复制到redisCluster文件夹下

逐个修改配置文件，调整端口号，开启集群

起6个redis主机

创建集群（分配槽）（三主7000，8000，9000 三从：7001，8001，9001）

redis-cli --cluster create --cluster-replicas 1 192.168.91.100:7000 192.168.91.100:8000 192.168.91.100:9000 192.168.91.100:7001 192.168.91.100:8001 192.168.91.100:9001

系统会询问你确认信息 回答yes

测试：在7000主机上set（keyvalue） key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，得出结果映射到8000主机，在8001从机上查看，得到value值，集群测试完成。

注意

关闭防火墙
centos7连接外网
每当修改redis配置文件，记得重启redis进程