主从复制
虽然redis有持久化机制，但是有时redis服务器重启也会丢失数据，因为redis重启后会将硬盘中的数据恢复到内存中，但是当redis服务器的硬盘损坏了可能就会导致数据丢失，如果通过redis的主从复制就能很好的避免这种单点故障。
主redis数据库有两个从redis，即使其中一台服务器宕机，其他两台服务器照样可以正常工作
主redis和从redis是保持实时同步的，当主redis写入数据时通过主从复制机制会复制到两个从redis服务器上。
只有一个主redis，可以有多个从redis
主从复制不会阻塞主redis，在同步数据时，主redis可以继续处理客户端的请求
一个redis可以既是主又是从
主从配置
主redis配置：
无需特殊配置
从redis配置：
修改redis服务器上的redis.conf配置文件，添加slaveof 主redis ip 主redis端口
说明当前从redis服务器对应主redis服务器的的IP,端口
主从复制过程
完成复制过程
在redis2.8之前主从复制过程如图：
复制过程:
- slave服务启动，slave会建立和master的联系，发送sync同步命令
- master启动一个后台进程将数据库快照保存到rdb文件中
此时如果生成rdb文件过程中存在写数据操作会导致rdb文件和当前主redis数据不一致，所以此时master主进程会开始收集写命令缓存起来
- master就发送rdb文件给slave
- slave将rdb文件保存在磁盘中，加载到内存中恢复
- master把缓存命令转发给slave
后续master收到的写命令会通过之前建立的连接发送给slave，当master和slave连接断开时slave会自动重新建立连接，如果master同时收到多个slave发来的命令时，只启动一个进程写数据库镜像，发送给多个slave。
完成复制过程的问题：
Redis2.8之前从redis每次同步会从主redis复制全部数据，如果从redis是新建立的从主redis复制全部数据是没有问题的，但是如果当从redis停止运行，再启动运行时可能只有少部分数据不同步，这时从redis又要从主redis复制全部数据，这样性能肯定没有复制那一小部分没有同步数据快。
部分复制：
部分复制说明：
从redis连接主redis时，会主动发起psync命令，从机会提供主机的runid（机器标识，随机生成）和offset（数据偏移量，如果主从offset不一致则说明数据不同步）主机验证runid和offset是否有效，runid相当于主机身份验证码，用来验证从机上一次连接的主机，如果runid验证未通过则进行全同步（首次同步），验证通过则说明曾经同步过，根据offset同步部分数据。
持久化：
在这里顺便介绍下redis的持久化。
Redis的高性能是由于其数据全部存储到内存中，为了是redis重启后保证数据不会丢失，需要把redis内存中的数据同步到硬盘中，这一过程就是持久化。
RDB持久化：
RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时redis会自动将内存中的数据进行快照并持久化到硬盘中。
save 900 1
save 300 10
save 60 10000
save开头的一行就是持久化配置，可以配置多个条件(每一行配置一个条件)，每个条件时“或”的关系，“save 900 1”表示15分钟（900秒）内至少1个键被更改则进行快照，
“save 300 10”表示5分钟（300秒）内至少10个键被更改则进行快照。
在redis.conf中
配置dir指定rdb快照文件的位置
配置dbfilenam指定rdb快照文件名
redis启动后会读取rdb快照文件，将数据从硬盘中加载到内存中，根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费20～30秒钟。
问题总结：
通过RDB方式实现持久化，一旦redis异常退出，就会丢失最后一次快照以后更改的所有数据。一般根据应用场景来进行合理持久化将数据损失控制在接受范围内，如果是很重要的数据可以通过AOF方式持久化。
AOF持久化
默认情况下redis没有开启AOF（append only file）方式持久化，可以通过appendonly参数开启：
appendonly yes
开启AOF持久化后每执行一条会更改redis中的数据的命令，redis就会将该命令写入硬盘中的aof文件，aof文件保存位置和rdb文件保存位置相同，都是通过dir参数设置的，默认的文件名为appendonly.aof ， 可以通过appendfilename参数修改：appendfilename appendonly.aof
来源：oschina
链接：https://my.oschina.net/u/4347493/blog/4123884