Redis-持久化+主从架构

Redis的持久化

Redis服务的前言：

数据丢失问题：实现Redis持久化，用备份
并发能力问题：单节并发度较低，搭建主从集群，实现读写分离
储存能力问题：搭建分片集群，利用插槽机制实现动态扩容
故障恢复问题：redis宕机，服务不可用，会出现很多状况，需要自动故障恢复手段，哨兵，实现健康监测和自动恢复

RDB模式

RDB被称为Redis数据快照， 记录内存数据到磁盘中，当Redis实例故障重启后，会从磁盘读取快照文件恢复数据；

快照文件为RDB文件，默认保存在当前运行目录，有两种保存方式：save，bgsave，Redis挂了也会执行一次RDB；

bgsave:创建一个子进程——>通过fork主进程得到，子进程共享主进程内存数据，然后将fork完的内存数据写入redis中；

save是由Redis主进程来执行save，回阻塞所有命令，所以一般都使用bgsave

也可以自动触发RDB：
在redis.conf下有Redis触发RDB的机制

RDB其他配置

压缩rdb文件到磁盘：rdbcompression yes
文件保存路径目录：dir ./
rdb文件改了名称后会丢失数据

时间不能太长也不能太短，因为太短，如果数据量很大比如1g，你1s一次来不赢，压力很大；
时间太长，你写入数据比较快，然后挂了，那么数据就会丢失保存不了

所以一般用默认的RDB触发时间就行了

异步持久化的实现

我们主进程用的是虚拟内存，其实也就是本机内存的一部分，然后其他物理内存中的数据的调用，是由于页表的作用——>操作系统会维护页表，主进程通过页表中的映射关系得到物理内存中的数据；

而我们这里的的异步持久化——>作用就是主进程fork了一个子进程，因为子进程此时与主进程的作用是一样的，所以也可以对物理内存的数据进行读写；

fork子过程拷贝页表是阻塞的；

从而达到内存共享，子进程对内存数据进行读写，实现异步持久化

copy-on-wirte技术：

当出现读写操作时，一个进行读：读取共享内存；一个进行写，当执行写操作时，内存中的数据（read-only）会被拷贝一份数据放在内存中给其他线程进行读取；

每更新一次，或者说更新的时候每有进程来读取都会有一个新的数据副本

AOF模式

appendfsync always：表示执行一次命令，主进程接收到命令，分配内存进行执行，然后持久化到硬盘——>安全；

appendfsync everysec：将命令执行放入缓冲区中，然后每秒将缓冲区中的数据写入AOF文件，如果途中宕机，有丢掉数据的风险；

appendsync no：这个的话，写命令完成后，它会被放到AOF缓冲区，但是缓冲区的数据什么时候写回给磁盘是由操作系统决定的

进行配置

save " ":禁用rdb

开启AOF：appendonly yes

重启后也会数据持久化到硬盘

注意：AOF记录的操作的命令数，只要你是个命令都会被记录到AOF配置文件中，而rdb文件，记录的是值，只有不同的值才会被记录到其中，有对象treeset和hashset

所以说，AOF文件会比RDB文件大的多，会记录对同一个key的多次写操作

执行BGREWRITEAOF命令

重写AOF

总结

RDB宕机恢复速度>AOF宕机恢复速度，因为RDB里面放的是数据，AOF放的是命令还需要执行，所以肯定慢些赛；

RDB数据恢复优先级<AOF，因为数据完整性较低，rdb可以充当一个备份的作用，比如主从集群时，rdb文件能够帮助恢复数据；

RDB系统资源占用较高，容易丢数据，备份时间较长，save xxx xxx，需要考虑时间长短一次备份，而AOF主要磁盘IO资源，因为其他线程需要重写命令；

Redis的主从架构

像我们redis的话，其实大部分都是用在读上面；

我们单节点的并发能力是有限的，可以试想一下，把读写操作进行分离，主节点进行写操作，从节点进行读操作；

从节点是主节点fork得到的，主从数据同步

1.端口以及文件调试测试

创建三个文件7001,7002,7003
1.首先开启3个节点，需要准备三份不同的配置文件和目录，配置文件所在的目录就是工作目录

将配置文件分别拷贝到文件目录中

2. 修改工作目录以及port

 sed -i -e 's/6379/7001/g' -e 's/dir .\//dir \/etc\/7001\//g' 7001/redis.conf

发现以及配置成功，工作目录以及端口成功被修改

3.还需要修改每个节点声明的IP，因为虚拟机本身有多个IP，为了避免混乱，需要再redis.conf中指定每一个实例的绑定IP信息

声明IP地址成功

2.主从配置

先redis-cli -p 端口号：当前节点连接端口

然后slaveof设置主从

数据同步完成

3.数据同步原理（第一次同步为全局同步）

1.其实就是rdb文件，从机调用slaveof命令后——>从机请求master，master判断从机是不是第一次数据同步，是的话就将rdb文件发送给从机（主机执行bgsave命令生成并发送rdb），从而实现数据同步（第一次是从机主动请求的）
2.然后从机先清空本地数据，然后加载rdb文件
3.后面主机再对数据更新，主机会自动给从机主动发送repl_baklog命令，从机接收到命令后执行

repl_baklog：

它是针对部分复制，储存未来新增的命令，里面有偏移量offset，就是增量同步

4.增量同步

增量同步就是全量同步后，主从同步数据而方式；

流程：

1.slave进行重启后，因为从机宕机了，所以主机的写数据从机是不知道的；
2.从机醒来后，会向主机发送请求，然后请求判断id固然是一样的，然后从repl_baklog中获取从机offset后的数据；
3.然后从机执行

注意：如果欠的数据>一圈了，因为repl_baklog大小是有上限的，写满后会覆盖最早的数据，而从机slave断开的时间又很久——>导致数据被覆盖，无法增量同步，只能全量同步；(可以将repl_baklog 文件大小设置大一点 或者 尽量不要让从机长时间宕机)

5.主从配置优化

1.在master中的配置文件配置repl-diskless-sync yes：启用无磁盘复制，这样我们的数据不会经过磁盘读写，而是直接将数据放到网络中，通过网络进行传输； 如果网络非常之慢的话就还是用磁盘复制

2.可以适当提高repl_baklog的大小，因为我们出现全量同步的原因就是repl_baklog小了，数据量大过了这个圈从而导致覆盖；
3.限制master上slave节点的数量，当从节点过多，可以采用主-从链式结构，减轻主机压力

6.问:master主机怎么判断从机slave是不是第一次同步数据？

Replication id：数据集的标记，id一致则是同一数据集，每一个master都有唯一Replication id，slave从机会继承主机master的Replication id；第一次主机和从机标记中的偏移量是一样的，也就是数据是一致的

offset：偏移量，当主机数据写入，那么repl——baklog中的数据会越来越多。而从机完成同步时也会记录同步的offset，如果从机salve的offset<master主机的offset，就说明从机的数据落后于主机，需要更新；

主机首先会根据Replication id进行判断，因为从机一开始也是自己的主机，所以id肯定是不一样的，如果是第一次，那么将主机id给到从机，并将offset传入，然后从机保存版本信息，那么就表示了从机与主机数据一致

1.主从机先进行连接，然后从机发送增量同步请求
2.主机说你的id与我的不匹配，你是第一次来，不能给你增量同步，只能全量同步

3.从机开始全量同步 ，然后接收主机的数据并将自己之前数据清空进行同步