一、准备工作
在/usr/local/redis（Redis的启动目录）中复制3个redis.conf文件用于启动3个Redis实例在一台服务器上模拟主从复制。
1）redis6379.conf中需要修改的内容如下：
dbfilename dump_6379.rdb
logfile “6379.log”
pidfile/var/run/redis_6379.pid
2)redis6380.conf和redis.6381.conf除了和redis6379.conf一样需要修改相应的配置外，还需要将port 分别改为6380和6381。
2)启动3个实例测试redis状态
使用bin/redis-server ./redis6379.conf指定启动redis使用的配置文件，这样redis就可以以守护进程的方式后台运行。启动客户端默认是6379端口的，如果不是默认端口需要使用-p命令指定启动端口：/bin/redis-cli –p 6380
二、配置主从复制
1、使用info命令可以看到redis的详细信息，使用inforeplication可以看到相关连接信息，role表示角色，master表示主机，slave表示从机，connected_slaves表示连接到主机的从机数量。
2、配置6380和6381端口启动的redis为6379端口启动的redis的从机：
分别连接6380和6381端口启动的redis客户端，键入：slaveof127.0.0.1 6379（这里3个redis实例都是在同一台服务器，如果不是就需要将127.0.0.1改为相应的主机IP地址）。
这时可以看到6379端口redis的连接状态是主机，连接的从机是两个，并列出了从机的IP地址和端口号。
连接一个从机的客户端输入info replicaiton可以看到从机的状态：role是slave，主机IP地址和端口号，master_link_status:up表示连接成功。
3、测试主从复制
1）连接主库，通过redis命令简单测试：
可以看到在主库使用set foo bar存入一个键，在两个从库可以获取到主库存入的键值，说明主从复制成功。
2）现在在从库输入set foo hi测试发现报错：(error) READONLY You can't write againsta read only slave.
这就是master-slave机制的读写分离，在主库设置的键值在从库不能修改。
如果想要从库也可以修改从主库同步过来的键值，可以修改配置文件中的slave-read-only为no。
重启修改配置的从库，连接客户端输入slaveof 127.0.0.1 6379重新连接主库，这时虽然可以修改从库的键值，但是连接主库客户端获取键值发现并没有改变，然后修改主库的键值再登录从库可以发现从库的键值又被主库的值覆盖了。
3）模拟主机故障
6379端因故障被关闭时，可以发现从库的数据备份依然存在，且状态是从服务器的状态，master_link_status:down。
6379端重新登录后依然是两个从服务器的主服务器。
4）模拟从服务器故障
上面已经提到过，如果从服务器故障，重启后会变成主机状态，需要重新输入slaveof ip 端口变成主服务器的从服务器。
5）修改主从关系
现在6380和6381都是6379的从服务器，如果将6381客户端输入slaveof127.0.0.1 6380，这时6381就变成了6380的从服务器，而6380是6379的从服务器。
恢复为一主两从的主从模式，如果主服务器6379宕机，这时的策略是将其中一台从服务器作为主机，另一台作为从机，将6381状态改为6380的从机：slaveof 127.0.0.1 6380，如果6379恢复，这时6380和6381不会自动变成6379的从服务器，因为6380/和6381已经自成一套体系。
5）哨兵模式
实际生产环境中，如果主服务器宕机，我们不可能手动修改从服务器为主服务器，需要从服务器能自动转换身份，可以通过哨兵模式来实现。
在Redis的工作目录中新增一个名为Sentinel.conf的配置文件，在文件中加入sentinelmonitor 被监控数据库名字（自己定义） 127.0.0.1 6379 1。最后一个数字1表示主服务器宕机后，投票看哪个从服务器接替主服务器，得票数多的服务器为主机。然后在/root目录下执行/ /usr/local/redis/bin/redis-sentinel sentinel.conf。
重新打开一个终端，现在让主服务器6379停机，可以在哨兵模式的终端中看到一些信息：
然后再查看6380和6381服务器的状态，可以看到一个服务器变成了另一个服务器的从服务器。
恢复原来的主服务器后，连接客户端可以看到原来的主服务器也变成了新的主服务器的从服务器。
