复制的目的：创建具有相同数据库的拷贝服务器；扩展系统处理读请求的能力；
复制的定义
Redis的复制（replication）功能允许用户根据一个Redis服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器则称为从服务器（slave）；
主从服务器两者拥有相同的数据库数据：只要主从服务器之间的网络连接正常，主服务器就会一直将发生在自己身上的数据更新同步给从服务器，从而一直保证主从服务器的数据相同；
一个主服务器可以拥有1到N个从服务器；
使用从服务器来处理读命令请求，通过复制来扩展系统处理读请求的能力
Redis允许从服务器执行客户端发送的命令请求，比如：GET、LRANGE等；
因为主从服务器拥有相同的数据库数据，所以从服务器在执行客户端发送的读命令时，获得的结果与主服务器执行相同的读命令所获得的结果是一样的；
所以用户可以将原本由主服务器负责处理的一部分（甚至全部）读命令请求转交给从服务器处理，从而降低主服务器在处理读命令请求方面的负载，并扩展整个系统处理读命令请求的能力；
通过添加从服务器可以线性地扩展整个系统处理读命令请求的能力
从服务器的创建与使用
创建从服务器，Redis提供了两种方法为某个主服务器创建从服务器
1、使用SLAVEOF master-ip master-port命令
比如：向一个服务器发送slave hadoop000 6379，可以让接收到该命令的服务器变为hadoop000:6379的从服务器；
在将一个服务器设置成从服务器后，可以通过向它发送SLAVEOF no one命令来让它变回一个主服务器（数据库已有的数据会被保留）；
2、配置文件中配置：slaveof master-ip master-port 选项来让服务器成为指定服务器的从服务器；
例如：如果客户端对服务器127.0.0.1:6380发送命令SLAVEOF 127.0.0.1 6379，那么127.0.0.1:6380将成为127.0.0.1:6379的从服务器；
主从服务器操作示例：
127.0.0.1:6379> SET msg "hello world" OK 127.0.0.1:6380> GET msg "hello world" 127.0.0.1:6379> INCR counter (integer) 1 127.0.0.1:6379> INCR counter (integer) 2 127.0.0.1:6380> GET counter "2" 127.0.0.1:6379> RPUSH lst 1 3 5 7 9 (integer) 5 127.0.0.1:6380> LRANGE lst 0 -1 1)"1" 2)"3" 3)"5" 4)"7" 5)"9"
服务器下线处理
主服务器或者从服务器下线了，怎么办？
服务器在复制时遭遇下线
在一个由主服务器和从服务器组成的系统中，主服务器或从服务器都有可能会下线，但是不同服务器下线带来的影响并不相同：
从服务器下线：整个系统处理读请求的性能将有所下降，但整个系统仍然可以继续处理写请求和读请求，并不会导致系统停机；
从服务器下线图例描述：
从服务器 B 下线，导致客户端C的访问失败，但只要客户端C改为访问其他在线的服务器，就可以解决这个问题。
主服务器下线：因为在整个系统中只有主服务器能处理写请求，那么主服务器下线后整个系统只能处理读请求而无法处理写请求，导致系统停机；
主服务器下线导致主从服务器的连接中断，并使得整个系统无法再执行写命令。这时从服务器还是可以继续处理读请求的，但是从服务器的数据会因为主服务器下线而没办法再得到更新。
让系统重新上线
为了让系统能够重新正常上线状态（让系统中的服务器既能处理读请求，又能处理写请求），用户需要向系统中的某一个从服务器发送SLAVEOF no one命令，让它自己变成新的主服务器，并向其他从服务器发送SLAVEOF命令，让它们去复制新的从服务器。
现在系统有了新的主服务器，以及一个从服务器，客户端可以继续使用这个系统来处理读请求和写请求了。
因为有一台服务器下线了的缘故，所以重新上线的系统在性能方面可能比不上原有的系统，但这种恢复操作可以避免整个系统停机。
虽然上面介绍的方法可以让系统重新上线，但手动来执行这些操作实在太麻烦了，为此，Redis 提供了 Sentinel 程序，用户可以使用Sentinel 来自动检测主从服务器的状态，并在主服务器下线时，自动执行故障转移操作（failover），让系统重新上线。
