1.主从模式介绍
Redis的主从复制功能非常强大，一个master可以拥有多个slave，而一个slave又可以拥有多个slave，如此下去，形成了强大的多级服务器集群架构。下面是关于redis主从复制的一些特点：
• master可以有多个slave
• 除了多个slave连到相同的master外，slave也可以连接其他slave形成图状结构
• 主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时，master可以继续处理client发来的请求。相反slave在初次同步数据时则会阻塞不能处理client的请求。
• 主从复制可以用来提高系统的可伸缩性,我们可以用多个slave 专门用于client的读请求，比如sort操作可以使用slave来处理。也可以用来做简单的数据冗余
• 可以在master禁用数据持久化，只需要注释掉master 配置文件中的所有save配置，然后只在slave上配置数据持久化。
1.1 主从复制原理
Slave启动成功连接到master后会发送一个sync命令。Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步(全量复制 )。
全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步。
但是只要是重新连接master,一次完全同步（全量复制)将被自动执行。
1.2 主从复制优点
通过配置多个Redis实例，数据备份在不同的实例上，主库专注写请求，从库负责读请求，这样的好处主要体现在下面几个方面：
• 高可用性 :在一个Redis集群中，如果master宕机，slave可以介入并取代master的位置，因此对于整个Redis服务来说不至于提供不了服务，这样使得整个Redis服务足够安全。
• 高性能 :在一个Redis集群中，master负责写请求，slave负责读请求，这么做一方面通过将读请求分散到其他机器从而大大减少了master服务器的压力，另一方面slave专注于提供读服务从而提高了响应和读取速度。
• 水平扩展性 :通过增加slave机器可以横向（水平）扩展Redis服务的整个查询服务的能力。
1.3 主从复制缺点
复制提供了高可用性的解决方案，但同时引入了分布式计算的复杂度问题，认为有两个核心问题：
• 数据一致性问题，如何保证master服务器写入的数据能够及时同步到slave机器上。
• 编程复杂，如何在客户端提供读写分离的实现方案，通过客户端实现将读写请求分别路由到master和slave实例上。
• 复制延时:由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
2.哨兵模式介绍
Redis的哨兵模式用于为Redis实现高可用，在主从分离的模型中，如果主服务器宕机了，那么哨兵将会选举主服务器下的一台从服务器升级为主服务器提供服务。
redis本身就支持主从集群，下面我们就来动手搭建一个一主两从的redis集群，即：分别实现主从模式和哨兵模式
3.主从模式集群的搭建
3.1 环境准备
这里使用三台服务器，每台服务器上开启一个redis-server和redis-sentinel服务，redis-server端口为6379，redis-sentinel的端口为6800，修改默认端口是安全的第一步。
redis-server说明
10.211.55.102:8000 主
10.211.55.103:8000 从
10.211.55.104:8000 从
redis-sentinel说明
10.211.55.102:8000 主
10.211.55.103:8000 从
10.211.55.104:8000 从3.2 搭建redis系统
先在三台机器上安装redis，具体步骤可参考Linux下redis安装（单机版）:
3.2.1 安装完成后复制redis提供的默认配置文件
cp /usr/local/redis-4.0.14/redis.conf /etc/redis.conf3.2.2 修改配置文件
cd /etc/
vim redis.conf3.2.3 主节点10.211.55.102上的配置
port 8000
daemonize yes
bind 10.211.55.102
masterauth 123456
requirepass 123456
pidfile /var/run/redis-8000.pid
logfile /var/log/redis/redis-8000.log3.2.4 从节点10.211.55.103，10.211.55.104 上的配置
port 8000
daemonize yes
bind 10.211.55.103，#10.211.55.104
requirepass 123456
masterauth 123456
pidfile /var/run/redis-8000.pid
logfile /var/log/redis/redis-8000.log
slaveof 10.211.55.102 8000注意：redis不会帮我们创建目录，所以在启动之前需要创建目录/var/log/redis3.3 启动三台机器上的redis
/usr/local/redis/bin/redis-server /etc/redis.conf3.4 测试
三个redis服务启动完毕后，进入命令行，执行info replication查看当前主从配置
3.4.1 主节点配置：
3.4.2 从节点配置
4.哨兵模式集群的搭建（我们将哨兵模式配置在102机器中，一般在生产中哨兵模式单独一台服务器部署，避免挂点）
模式模式只需要在主从的基础下修改如下参数：4.1 将sentinel.conf复制到指定的目录
/usr/local/redis/bin/redis-server /usr/local/redis/sentinel.conf4.2 修改里面的如下参数 哨兵的启动和redis-server的启动没有关系，一个哨兵的集群可以监控多个不同的redis主从实例
4.2.1 sentinel monitor master-name ip redis-port quorum
例：sentinel monitor mymaster 192.168.98.136 6379 1
quorum：quorum个sentinel认为master死了时，才能真正认为该master已经不可用了(sentinel集群中各个sentinel也有互相通信，通gossip协议)。
4.2.2 sentinel auth-pass mymaster mypwd
连接master 需要的密码
4.2.3 down-after-milliseconds
sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了(subjectively down, 也简称为SDOWN)。而这个down-after-milliseconds就是用来指定这个“一定时间范围”的，单位是毫秒。
注：哨兵不会马上进行failover主备切换，因为还要考虑其他哨兵的意见，需要超过某个数量的哨兵都认为master凉凉了，才会准备进行准备切换。在这个时候也不是马上就能failover的，还是需要需要sentinel中的大多数sentinel授权后才可以进行failover
例如，集群中有5个sentinel，票数被设置为2，当2个sentinel认为一个master已经不可用了以后，将会触发failover，但是，进行failover的那个sentinel必须先获得至少3个sentinel的授权才可以实行failover。
如果票数被设置为5，要达到ODOWN状态，必须所有5个sentinel都主观认为master为不可用，要进行failover，那么得获得所有5个sentinel的授权。
4.2.4 protected-mode
这个属性在哨兵设置中很容易出现坑，由于哨兵间需要进行通信进行授权，所以这个属性设置为yes时只可以进行内网访问，看服务器的情况如果主从切换失败了，可以试试把这个属性设置为no。4.3 启动哨兵
/usr/local/redis/bin/redis-server /usr/local/redis/sentinel.conf --sentine &4.4 第三步 测试
关掉10.211.55.102: 中redis
会从10.211.55.103或10.211.55.104 中选出主节点
当10.211.55.102 中redis 启动，会加入到从节点中
