【Redis6--4】Redis持久化，主从复制，哨兵，集群

目录

1.Redis持久化之RDB

1.1是什么

1.2备份是如何执行的

1.3Fork

1.4RDB持久化流程

1.5dump.rdb文件的备份

​​​​​​​1.6优势

 1.7劣势

1.8总结

2.Redis持久化之AOF

2.1是什么

2.2​​​​​​​AOF持久化流程

​​​​​​​2.3AOF同步频率设置

2.4​​​​​​​Rewrite压缩

1.是什么：

2.重写原理，如何实现重写

3.重写流程

2.5 优势

2.6劣势

2.7总结

 AOF和RDB总结

3.主从复制

1.​​​​​​​是什么

2.能做什么

3.实现主从复制

​​​​​​4.​常见三种问题

4.1​​​​​​​.一主二仆

4.2​​​​​​​.薪火相传

4.3.反客为主

5.复制原理

​​​​​​​3.哨兵模式(sentinel)

​​​​​​​1.是什么​​​​​​​​​​​​​​

2.常见问题

4.Redis集群

​​​​​​​1.问题引入

2.什么是集群

​​​​​​​3.故障恢复

​​​​​​​Redis 集群提供了以下好处

Redis 集群的不足

---

1.Redis持久化之RDB

1.1是什么

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

​​​​​​​1.2备份是如何执行的

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

​​​​​​​1.3Fork

1. Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
2. 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
3. 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

​​​​​​​写时复制技术：在数据第一次写入到某个存储位置时，首先将原有内容拷贝出来，写到另一位置处，然后再将数据写入到存储设备中，该技术只拷贝在拷贝初始化开始之后修改过的数据。

​​​​​​​1.4RDB持久化流程

​​​​​​​1.5dump.rdb文件的备份

先通过config get dir  查询rdb文件的目录

将*.rdb的文件拷贝到别的地方

rdb的恢复

1. 关闭Redis
2. 启动Redis, 备份数据会直接加载
3. 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb

​​​​​​​1.6优势

1. 适合大规模的数据恢复
2. 对数据完整性和一致性要求不高更适合使用
3. 节省磁盘空间
4. 恢复速度快

​​​​​​​​​​​​​​​​​​​​​

 1.7劣势

1. Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
2. 虽然Redis在fork时使用了写时复制技术,但是如果数据庞大时还是比较消耗性能。
3. 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

1.8总结

2.Redis持久化之AOF

2.1是什么

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

2.2​​​​​​​AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

​​​​​​​AOF默认不开启

可以在redis.conf中配置文件名称，默认为 appendonly.aof

AOF文件的保存路径，同RDB的路径一致。

​​​​​​​1.AOF和RDB同时开启，redis听谁的？

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

​​​​​​​2.3AOF同步频率设置

appendfsync always

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

2.4​​​​​​​Rewrite压缩

1.是什么：

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

2.重写原理，如何实现重写

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appendfsync-on-rewrite：

如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

      如果 no-appendfsync-on-rewrite=no,  还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

触发机制，何时重写

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）

auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,

如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

3.重写流程

（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。

（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

（4）1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

2.5 优势

1. 备份机制更稳健，丢失数据概率更低。
2. 可读的日志文本，通过操作AOF稳健，可以处理误操作。

2.6劣势

1. 比起RDB占用更多的磁盘空间。
2. 恢复备份速度要慢。
3. 每次读写都同步的话，有一定的性能压力。
4. 存在个别Bug，造成恢复不能。

2.7总结

 AOF和RDB总结

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

3.主从复制

1.​​​​​​​是什么

主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

2.能做什么

1. 读写分离，性能扩展
2. 容灾快速恢复

3.实现主从复制

拷贝多个redis.conf文件include(写绝对路径)

开启daemonize yes

Pid文件名字pidfile

指定端口port

Log文件名字

dump.rdb名字dbfilename

Appendonly 关掉或者换名字

​​​​​​​新建redis6379.conf，填写以下内容

include /myredis/redis.conf

pidfile /var/run/redis_6379.pid

port 6379

dbfilename dump6379.rdb

​​​​​​​新建redis6380.conf，填写以下内容

​​​​​​​新建redis6381.conf，填写以下内容

slave-priority 10

设置从机的优先级，值越小，优先级越高，用于选举主机时使用。默认100

​​​​​​​启动三台redis服务器

​​​​​​​查看系统进程，看看三台服务器是否启动

​​​​​​​查看三台主机运行情况

info replication

打印主从复制的相关信息

​​​​​​​配从(库)不配主(库)

slaveof 

成为某个实例的从服务器

1、在6380和6381上执行: slaveof 127.0.0.1 6379

2、在主机上写，在从机上可以读取数据

在从机上写数据报错

3、主机挂掉，重启就行，一切如初

4、从机重启需重设：slaveof 127.0.0.1 6379

可以将配置增加到文件中。永久生效。

​​​​​​4.​常见三种问题

4.1​​​​​​​.一主二仆

1.如果其中一台从机发生宕机期间，主机又进行了写入操作，那么等宕机的从机重新启动后会自动复制主机写的所有内容，包括宕机期间进行的写操作

2.当主机宕机后，从机依旧是从机，不会变成主机

3.当主机重新连接后进行写操作，从机依旧可以查看

4.2​​​​​​​.薪火相传

一个主机可以有从机，同样他的从机也可以有自己的从机，可以有效减轻master的写压力,去中心化降低风险。（可以用java中父类，子类，子类的子类进行类比）

风险是一旦某个slave宕机，后面的slave都没法备份

主机挂了，从机还是从机，无法写数据了

4.3.反客为主

当一个主机宕机后，后面的从机可以立刻升为主机，其后面的从机不用做任何修改。

用 slaveof  no one  将从机变为主机。​​​​​​​

5.复制原理

1.从机启动成功连接到主机后会发送一个sync命令

2.主机接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，主机将传送整个数据文件到从机,以完成一次完全同步

全量复制：从机服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：主机继续将新的所有收集到的修改命令依次传给从机,完成同步

但是只要是重新连接主机（从机挂了又连接）,一次完全同步（全量复制)将被自动执行

​​​​​​​3.哨兵模式(sentinel)

​​​​​​​1.是什么

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

 

2.常见问题

1.当主机挂掉，从机选举中产生新的主机

        哪个从机会被选举为主机呢？根据优先级别：slave-priority

2.原主机重启后会变为从机。

3.复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

4.故障恢复

优先级在redis.conf中默认：slave-priority 100，值越小优先级越高

偏移量是指获得原主机数据最全的

每个redis实例启动后都会随机生成一个40位的runid

4.Redis集群

​​​​​​​1.问题引入

容量不够，redis如何进行扩容？

并发写操作， redis如何分摊？

另外，主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。

之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置。

2.什么是集群

Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

​​​​​​​3.故障恢复

如果主节点下线？从节点能否自动升为主节点？注意：15秒超时

主节点恢复后，主从关系会如何？主节点回来变成从机。

如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续?

如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么 ，整个集群都挂掉

如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。

​​​​​​​Redis 集群提供了以下好处

实现扩容

分摊压力

无中心配置相对简单​​​​​​​

Redis 集群的不足

多键操作是不被支持的

多键的Redis事务是不被支持的。lua脚本不被支持

由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。