本文已参与「新人创作礼」活动，一起开启掘金创作之路。
一，概述
1、redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。
2、通过redis的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。
主从复制过程：见下图
编辑
过程：
1：当一个从数据库启动时，会向主数据库发送sync命令，
2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来
3：当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库。
4：从数据库收到后，会载入快照文件并执行收到的缓存的命令。
二，配置主从复制
redis主从复制实现起来非常简单，由于资源有限，我们在这采用伪集群的方式实现。一台机器上不同端口。
编辑
如上图复制三份redis 分别到6379，6380，6381 文件夹，文件夹根据启动端口名创建。
我们这里吧6379作为主的，其余的6380，6381作为从。
分别修改6380，6381配置文件。这里演示一个修改方法修改点都是一样的。
vi 6380/etc/redis.conf
编辑
编辑
#修改slave从redis中的 redis.conf文件,填写主服务器的ip和端口。
slaveof 192.168.1.48 6379
#主redis服务器配置了密码,则需要配置
masterauth 123456
配置完成查看效果。
分别启动(需要注意的是只有主节点可以进行写操作)
/usr/local/redis-cp/6379/bin/redis-server /usr/local/redis-cp/6379/etc/redis.conf
/usr/local/redis-cp/6380/bin/redis-server /usr/local/redis-cp/6380/etc/redis.conf
/usr/local/redis-cp/6381/bin/redis-server /usr/local/redis-cp/6381/etc/redis.conf
编辑
模拟三个窗口分别连接客户端
/usr/local/redis-cp/6379/bin/redis-cli -h 127.0.0.1 -p 6379 -a "123456"
/usr/local/redis-cp/6380/bin/redis-cli -h 127.0.0.1 -p 6380 -a "123456"
/usr/local/redis-cp/6381/bin/redis-cli -h 127.0.0.1 -p 6381 -a "123456"
编辑
#查看
info
编辑
下面模拟从节点6381宕机。
编辑
宕机恢复后正常同步数据，之前挂机期间的数据也可以正常同步。
下面模拟主节点挂机
编辑
直接报错，从节点不能进行写操作。what?我们尝试重启子节点6380，结果还是一样。
从上面可以看出redis自带的主从复制不能实现高可用，一旦主节点宕机以后，将会造成整个系统不可用。
那么有没有解决方法呢？答案是肯定的。我们引入哨兵机制。
三，哨兵机制实现高可用
什么是哨兵机制****
Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:
监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。
哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.
每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.
虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel).
哨兵(sentinel) 的一些设计思路和zookeeper非常类似
单个哨兵(sentinel)
编辑
哨兵机制实现
复制哨兵配置
cp sentinel.conf /usr/local/redis-cp/6379/etc/
编辑
修改sentinel.conf配置文件
vi /usr/local/redis-cp/6379/etc/sentinel.conf
#修改一下内容
sentinel monitor mymast 192.168.110.133 6379 1 #主节点 名称 IP 端口号 选举次数
sentinel auth-pass mymaster 123456
#修改心跳检测 30毫秒
sentinel down-after-milliseconds mymaster 30
#做多多少合格节点
sentinel parallel-syncs mymaster 2
编辑
先启动redis主，在启动redis从，再启动哨兵
启动哨兵
/usr/local/redis-cp/6380/bin/redis-server /usr/local/redis-cp/6379/etc/sentinel.conf --sentinel &
编辑
再分别启动客户端进行测试
关闭主节点6379
编辑
上图看出打印了一大堆日志。主节点选举的过程。
编辑
8380变成了主节点。测试正常。
编辑
设想一下，如果这时候6379恢复了。会不会重新切换回来？
测试下，我们启动6379
编辑
发现6379变成了slave，尝试获取值，发现获取不到？what?
这是一个大坑！！！
之前我们在从节点修改过这两个
#修改slave从redis中的 redis.conf文件,填写主服务器的ip和端口。
slaveof 192.168.1.48 6379
#主redis服务器配置了密码,则需要配置
masterauth 123456
但是我们之前的主节点6379没有修改这个，又因为从节点6380变成了主节点，6379需要同步但是它并不知道密码。
我们通知6379重新修改密码，重新启动。
编辑
启动测试
编辑
此时已经完成同步。
