一、Redis主从复制

概述

1、redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

2、通过redis的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。

 

主从复制过程：见下图

 

 

 

过程：

1：当一个从数据库启动时，会向主数据库发送sync命令，

2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来

3：当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库。

4：从数据库收到后，会载入快照文件并执行收到的缓存的命令。

 

进行配置过程

  一主多从实现

  介绍：  主服务器可以读写，但是从服务器只允许读。

  场景：

•  读写分离（读、写分别不同的库，增加整体的吞吐量）、
• 日志备份、高可用读写分离问题：
• 同步（redis自带解决方案）

 

Redis只能一个主，多个从:

 

 

过程（使用内网实现的通讯）:

1、 从服务器启动时候，会向Master发送sync命令.从服务器是指向主服务器的IP和端口号。

2、当Master接收到sync命令后，会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来。（一旦在主服务器有任何写的操作，都会有快照文件记录）

3、当快照完成后，redis会将快照文件和所有缓存的命令发送给Slave。

 

修改slave从redis中的 redis.conf文件

slaveof  ip + 端口 
masterauth 123456--- 主redis服务器配置了密码,则需要配置

 

直接服务器配置

 

 

  配置好了,启动主，再启动从。

 

结果验证:

 主服务器写入：

 

 

 从服务器可以读

 

 从服务器不可以写！

 

 

 

可以通过 info 查看标志：

信息一目了然

 

一个主 多个从的话 那就每个从都设置下 , 只能有一个主！！

 

二、Redis持久化

 什么是Redis持久化？

•  就是将内存数据保存到硬盘。

Redis 持久化存储方式:

•  AOF
•  RDB

 

 解释:

1. RDB 是以二进制文件，是在某个时间 点将数据写入一个临时文件（60s set 10个key），持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。

优点：使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能。开启单独的进程去做写的io操作和当前redis主进程没有任何关联。 
缺点：RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候,这里说的这个执行数据写入到临时文件的时间点是可以通过配置来自己确定的，通过配置redis 在 n 秒内如果超过 m 个 key 被修改这执行一次 RDB 操作。这个操作就类似于在这个时间点来保存一次 Redis 的所有数据，一次快照数据。所有这个持久化方法也通常叫做 snapshots。Redis的值存放在内存中，防止突然断电。对数据进行持久化的备份。非实时，突然断电，可能有一部分数据丢失

         

 验证RDB

 1.写入值 then 宕机

2.启动，读取值

3.默认开启了 rdb持久化

 

结论:

删除掉，在开启就查不到了哦。当服务器宕机后，以RDB进行持久化

配置文件就可以找到这个默认的配置：

 

在slave中:

 

 

300s 内做了 10次文件的保存 会生产rdb文件记录.

 

解释备注:

#dbfilename：持久化数据存储在本地的文件

dbfilename dump.rdb

#dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下

dir ./

##snapshot触发的时机，save   

##如下为900秒后，至少有一个变更操作，才会snapshot 

##对于此值的设置，需要谨慎，评估系统的变更操作密集程度 

##可以通过“save “””来关闭snapshot功能 

#save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key300s进行存储；更改10000个key60s进行存储。

save 900 1

save 300 10

save 60 10000

##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等 

stop-writes-on-bgsave-error yes 

##是否启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间 

rdbcompression yes 

 

2.AOF,Append-only file，将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在 append 操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程；当 server 需要数据恢复时，可以直接 replay 此日志文件，即可还原所有的操作过程。AOF 相对可靠，它和 mysql 中 bin.log、apache.log、zookeeper 中 txn-log 简直异曲同工。AOF 文件内容是字符串，非常容易阅读和解析。我们可以简单的认为 AOF 就是日志文件，此文件只会记录“变更操作”(例如：set/del 等)，如果 server 中持续的大量变更操作，将会导致 AOF 文件非常的庞大，意味着 server 失效后，数据恢复的过程将会很长；事实上，一条数据经过多次变更，将会产生多条 AOF 记录，其实只要保存当前的状态，历史的操作记录是可以抛弃的；因为 AOF 持久化模式还伴生了“AOF rewrite”。
AOF 的特性决定了它相对比较安全，如果你期望数据更少的丢失，那么可以采用 AOF 模式。如果 AOF 文件正在被写入时突然 server 失效，有可能导致文件的最后一次记录是不完整，你可以通过手工或者程序的方式去检测并修正不完整的记录，以便通过AOF 文件恢复能够正常；同时需要提醒，如果你的 redis 持久化手段中有 AOF ，那么在 server 故障失效后再次启动前，需要检测AOF 文件的完整性。

优点：可以保持更高的数据完整性，如果设置追加 file 的时间是 1s，如果 redis 发生故障，最多会丢失 1s 的数据；且如果日志写入不完整支持 redis-check-aof 来进行日志修复；AOF 文件没被 rewrite 之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的 flushall)。

缺点：AOF 文件比 RDB 文件大，且恢复速度慢。

 

验证AOF

AOF 实时日志记录形式 只会记录set之类的 写的操作  

1.配置时候 appendonly yes  就OK了

2.然后进行写入值：

3.最后看到这个文件：

这个日志文件 只会存放写的日志文件

get之类的肯定不会记录的哦 只会记录增 、删、 改的操作.由于是实时的 效率低 影响整体性能  AOF庞大的话 就很影响整体性能了。如果突然断电这样的情况 肯定AOF好！

 

总结:

AOF 是文件操作，对于变更操作比较密集的 server，那么必将造成磁盘 IO 的负荷加重；此外 linux 对文件操作采取了“延迟写入”手段，即并非每次 write 操作都会触发实际磁盘操作，而是进入了 buffer 中，当 buffer 数据达到阀值时触发实际写入(也有其他时机)，这是 linux 对文件系统的优化，但是这却有可能带来隐患，如果 buffer 没有刷新到磁盘，此时物理机器失效(比如断电)，那么有可能导致最后一条或者多条 AOF记录的丢失。通过上述配置文件，可以得知 redis 提供了 3 中 AOF记录同步选项：

1.always：每一条AOF 记录都立即同步到文件，这是最安全的方式，也以为更多的磁盘操作和阻塞延迟，是 IO 开支较大。

2.everysec：每秒同步一次，性能和安全都比较中庸的方式，也是 redis 推荐的方式。如果遇到物理服务器故障，有可能导致最近一秒内 AOF 记录丢失(可能为部分丢失)。

3.no：redis 并不直接调用文件同步，而是交给操作系统来处理，操作系统可以根据 buffer 填充情况 / 通道空闲时间等择机触发同步；这是一种普通的文件操作方式。性能较好，在物理服务器故障时，数据丢失量会因 OS 配置有关。

其实，我们可以选择的太少，everysec 是最佳的选择。如果你非常在意每个数据都极其可靠，建议你选择一款“关系性数据库”吧。
AOF 文件会不断增大，它的大小直接影响“故障恢复”的时间, 而且 AOF 文件中历史操作是可以丢弃的。AOF rewrite 操作就是“压缩”AOF 文件的过程，当然 redis 并没有采用“基于原 aof 文件”来重写的方式，而是采取了类似 snapshot 的方式：基于 copy-on-write，全量遍历内存中数据，然后逐个序列到 aof 文件中。因此 AOF rewrite 能够正确反应当前内存数据的状态，这正是我们所需要的；*rewrite 过程中，对于新的变更操作将仍然被写入到原 AOF 文件中，同时这些新的变更操作也会被 redis 收集起来(buffer，copy-on-write 方式下，最极端的可能是所有的 key 都在此期间被修改，将会耗费 2 倍内存)，当内存数据被全部写入到新的 aof 文件之后，收集的新的变更操作也将会一并追加到新的 aof 文件中，此后将会重命名新的 AOF文件为 appendonly.aof, 此后所有的操作都将被写入新的 aof 文件。如果在 rewrite 过程中，出现故障，将不会影响原 AOF 文件的正常工作，只有当 rewrite 完成之后才会切换文件，因为 rewrite 过程是比较可靠的。*

触发 rewrite 的时机可以通过配置文件来声明，同时 redis 中可以通过 bgrewriteaof 指令人工干预。

redis-cli -h ip -p port bgrewriteaof

因为 rewrite 操作 /aof 记录同步 /snapshot 都消耗磁盘 IO，redis 采取了“schedule”策略：无论是“人工干预”还是系统触发，snapshot 和 rewrite 需要逐个被执行。

AOF rewrite 过程并不阻塞客户端请求。系统会开启一个子进程来完成。

 

备注:

##此选项为aof功能的开关，默认为“no”，可以通过“yes”来开启aof功能  ##只有在“yes”下，aof重写/文件同步等特性才会生效 

appendonly yes 

##指定aof文件名称 

appendfilename appendonly.aof 

##指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec 

appendfsync everysec 

##在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no” 

no-appendfsync-on-rewrite no 

 

##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb” 

auto-aof-rewrite-min-size 64mb 

 
##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。 

##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后 

##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。  

 auto-aof-rewrite-percentage 100