redis主从配置
主从复制概念：主从复制，当用户往Master端写入数据时，通过Redis Sync机制将数据文件发送至Slave，Slave也会执行相同的操作确保数据一致；且实现Redis的主从复制非常简单。
主从复制特点
1、同一个Master可以拥有多个Slaves。
2、Master下的Slave还可以接受同一架构中其它slave的链接与同步请求，实现数据的级联复制，即Master->Slave->Slave模式；
3、Master以非阻塞的方式同步数据至slave，这将意味着Master会继续处理一个或多个slave的读写请求；
4、Slave端同步数据也可以修改为非阻塞是的方式，当slave在执行新的同步时，它仍可以用旧的数据信息来提供查询；否则，当slave与master失去联系时，slave会返回一个错误给客户端；
5、主从复制具有可扩展性，即多个slave专门提供只读查询与数据的冗余，Master端专门提供写操作；
6、通过配置禁用Master数据持久化机制，将其数据持久化操作交给Slaves完成，避免在Master中要有独立的进程来完成此操作。
三、redis主从配置
配置redis主从非常简单
1.注意防火墙，两边都打开6379端口，允许对付ip连接
2.修改配置文件bind ip， 将ip配置为本机内网ip，不要配置成127.0.0.1
3.slave 修改配置
slaveof 192.168.8.8 6379 （master ip master port）
四、redis持久化
redis持久化有两种方式：
1.rdb持久化
这个redis提供了rdb持久化功能，可以将redis在内存中的状态保存到磁盘中，可以手动执行，也可以在配置文件中配置定期执行
rdb持久化产生的rdb文件是一个经过压缩的二进制文件，这个文件被保存在硬盘中，redis可以通过这个文件还原数据库当时的状态
rdb可以通过两个命令来生成：
SAVE：阻塞redis的服务器进程，直到RDB文件被创建完毕。BGSAVE：派生(fork)一个子进程来创建新的RDB文件，记录接收到BGSAVE当时的数据库状态，父进程继续处理接收到的命令，子进程完成文件的创建之后，会发送信号给父进程，而与此同时，父进程处理命令的同时，通过轮询来接收子进程的信号。
而RDB文件的载入一般情况是自动的，redis服务器启动的时候，redis服务器再启动的时候如果检测到RDB文件的存在，那么redis会自动载入这个文件。
如果服务器开启了AOF持久化，那么服务器会优先使用AOF文件来还原数据库状态。
RDB是通过保存键值对来记录数据库状态的，采用copy on write的模式，每次都是全量的备份。BGSAVE可以在不阻塞主进程的情况下完成数据的备份。可以通过redis.conf中设置多个自动保存条件，只要有一个条件被满足，服务器就会执行BGSAVE命令。
# 以下配置表示的条件： # 服务器在900秒之内被修改了1次 save 900 1 # 服务器在300秒之内被修改了10次 save 300 10 # 服务器在60秒之内被修改了10000次 save 60 10000
关闭rdb:
(1)注释掉原来的持久化规则
#save 900 1 #save 300 10 #save 60 10000
(2)设置为空
save ""
2.AOF持久化
AOF持久化（Append-Only-File），与RDB持久化不同，AOF持久化是通过保存Redis服务器锁执行的写状态来记录数据库的。具体来说，RDB持久化相当于备份数据库状态，而AOF持久化是备份数据库接收到的命令，所有被写入AOF的命令都是以redis的协议格式来保存的。
在AOF持久化的文件中，数据库会记录下所有变更数据库状态的命令，除了指定数据库的select命令，其他的命令都是来自client的，这些命令会以追加(append)的形式保存到文件中。
服务器配置中有一项appendfsync，这个配置会影响服务器多久完成一次命令的记录：
always：将缓存区的内容总是即时写到AOF文件中。everysec：将缓存区的内容每隔一秒写入AOF文件中。no：写入AOF文件中的操作由操作系统决定，一般而言为了提高效率，操作系统会等待缓存区被填满，才会开始同步数据到磁盘。
redis默认实用的是everysec。
redis在载入AOF文件的时候，会创建一个虚拟的client，把AOF中每一条命令都执行一遍，最终还原回数据库的状态，它的载入也是自动的。在RDB和AOF备份文件都有的情况下，redis会优先载入AOF备份文件
AOF文件可能会随着服务器运行的时间越来越大，可以利用AOF重写的功能，来控制AOF文件的大小。AOF重写功能会首先读取数据库中现有的键值对状态，然后根据类型使用一条命令来替代前的键值对多条命令。
AOF重写功能有大量写入操作，所以redis才用子进程来处理AOF重写。这里带来一个新的问题，由于处理重新的是子进程，这样意味着如果主线程的数据在此时被修改，备份的数据和主库的数据将会有不一致的情况发生。因此redis还设置了一个AOF重写缓冲区，这个缓冲区在子进程被创建开始之后开始使用，这个期间，所有的命令会被存两份，一份在AOF缓存空间，一份在AOF重写缓冲区，当AOF重写完成之后，子进程发送信号给主进程，通知主进程将AOF重写缓冲区的内容添加到AOF文件中。
配置：
#AOF 和 RDB 持久化方式可以同时启动并且无冲突。 #no表示关闭AOF持久化，yes表示开启，如果AOF开启，启动redis时会加载aof文件，这些文件能够提供更好的保证。 appendonly yes # 只增文件的文件名称。（默认是appendonly.aof） # appendfilename appendonly.aof #redis支持三种不同的写入方式： # # no:不调用，之等待操作系统来清空缓冲区当操作系统要输出数据时。很快。 # always: 每次更新数据都写入仅增日志文件。慢，但是最安全。 # everysec: 每秒调用一次。折中。 appendfsync everysec # 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入.官方文档建议如果你有特殊的情况可以配置为'yes'。但是配置为'no'是最为安全的选择。 no-appendfsync-on-rewrite no # 自动重写只增文件。 # redis可以自动盲从的调用‘BGREWRITEAOF’来重写日志文件，如果日志文件增长了指定的百分比。 # 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。 auto-aof-rewrite-percentage 100 # 当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。 auto-aof-rewrite-min-size 64mb
对比：
AOF更安全，可将数据及时同步到文件中，但需要较多的磁盘IO，AOF文件尺寸较大，文件内容恢复相对较慢， 也更完整。AOF每次都要写到磁盘，对性能影响更大RDB持久化，安全性较差，它是正常时期数据备份及master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。
靠谱的持久化方案：
- Master上关闭AOF, 使用RDB或完全关持久化, 在某个slave上进行持久化.
- Master使用AOF, 允许AOF文件足够大,每天夜间业务量小的主动执行Rewrite命令.
- Master执行RDB, slave上执行AOF. 程序配合在slave执行rewrite时,把读改在master上.
注意RDB/AOF出来的文件最好备份到其它机器,你永远不知道机器什么时候down.
持久化对比
