我们一般都在一台服务器上进行操作的，也就是说读和写以及备份操作都是在一台Redis服务器上进行的，那么随着项目访问量的增加，对Redis服务器的操作也越加频繁，虽然Redis读写速度都很快，但是一定程度上也会造成一定的延时，那么为了解决访问量大的问题，通常会采取的一种方式是主从架构Master/Slave，Master 以写为主，Slave 以读为主，Master 主节点更新后根据配置，自动同步到从机Slave 节点。
1、修改配置文件
首先将redis.conf 配置文件复制三份，通过修改端口分别模拟三台Redis服务器。
修改 daemonize yes
配置PID文件路径 pidfile /var/redis/run/redis_6379.pid
配置端口 port 6379
配置log 文件名字 logfile "6379.log"
配置rdb文件名 dbffilename dump_6379.rdb
接下来我们分别启动这三个服务
redis-cli -p 6379
redis-cli -p 6380
redis-cli -p 6381
设置主从关系：
slaveof 127.0.0.1 6379
主节点 Maste 挂掉，从节点角色还是不会改变的。
哨兵模式
通过前面的配置，主节点Master 只有一个，一旦主节点挂掉之后，从节点没法担起主节点的任务，那么整个系统也无法运行。如果主节点挂掉之后，从节点能够自动变成主节点，那么问题就解决了，于是哨兵模式诞生了。
哨兵模式搭建步骤：
在配置文件目录下新建 sentinel.conf 文件，名字绝不能错，然后配置相应内容
sentinel monitor 被监控机器的名字(自己起名字) ip地址 端口号 得票数
sentinel monitor sentinel6379 127.0.0.1 6379 1
2.启动哨兵
redis-sentinel /etc/redis/sentinel.conf
哨兵模式也存在单点故障问题，如果哨兵机器挂了，那么就无法进行监控了，解决办法是哨兵也建立集群，Redis哨兵模式是支持集群的。
主从复制原理
Redis的复制功能分为同步（sync）和命令传播（command propagate）两个操作。
旧版同步
当从节点发出 SLAVEOF 命令，要求从服务器复制主服务器时，从服务器通过向主服务器发送 SYNC 命令来完成。该命令执行步骤：
1、从服务器向主服务器发送 SYNC 命令
2、收到 SYNC 命令的主服务器执行 BGSAVE 命令，在后台生成一个 RDB 文件，并使用一个缓冲区记录从开始执行的所有写命令
3、当主服务器的 BGSAVE 命令执行完毕时，主服务器会将 BGSAVE 命令生成的 RDB 文件发送给从服务器，从服务器接收此 RDB 文件，并将服务器状态更新为RDB文件记录的状态。
4、主服务器将缓冲区的所有写命令也发送给从服务器，从服务器执行相应命令。
命令传播
当同步操作完成之后，主服务器会进行相应的修改命令，这时候从服务器和主服务器状态就会不一致。
为了让主服务器和从服务器保持状态一致，主服务器需要对从服务器执行命令传播操作，主服务器会将自己的写命令发送给从服务器执行。从服务器执行相应的命令之后，主从服务器状态继续保持一致。
总结：通过同步操作以及命令传播功能，能够很好的保证了主从一致的特性。
缺点
主从复制虽然解决了主节点的单点故障问题，但是由于所有的写操作都是在 Master 节点上操作，然后同步到 Slave 节点，那么同步就会有一定的延时，当系统很繁忙的时候，延时问题就会更加严重，而且会随着从节点slave的增多而愈加严重。