目录

 入门demo

复制配置文件

启动三个实例 

 配置主从（配从不配主）

常用主从方案

一主二从

薪火相传

反客为主

哨兵模式

配置哨兵

启动哨兵

 复制延迟

选举策略

 入门demo

复制配置文件

一主二从，6380为主，6381和6382为从。复制三份redis.config：

分别修改配置文件pidfile、port、dbfilename避免冲突（以6380为例，其余两个类似）

pidfile /var/run/redis_6380.pid

port 6380

dbfilename dump6380.rdb

因为我设置了密码，所以还需要给从机额外配置，不然从机连不上主机

replicaof 127.0.0.1 6380
masterauth 主机密码

启动三个实例 

./redis-server ./msdemo/redis6380.conf
./redis-server ./msdemo/redis6381.conf
./redis-server ./msdemo/redis6382.conf

 此时虽然启动了三个redis实例，但并不具备主从属性，可以连接redis-cli用info replication查看：

 配置主从（配从不配主）

slaveof ip port

在端口6381的实例使用该命令，成功从master变为6380的slave

 6382实例同理，可以看到6380已经有两个从机了。

测试：在6380上写入数据，在6381和6382读取数据，可以看到6381和6382能够读取6380写入的数据，说明主从配置生效了

常用主从方案

非专业名词，三种方案名字都是别人乱起的。

一主二从

如上面的demo

 注意事项：

• 从机挂掉以后再连上不再是原来的从机了，变为独立的主机
• 从机连上主机后会将主机的数据从头读入
• 主机挂掉以后从机不做任何事情，待主机从新启动后主从关系仍在

薪火相传

此时的结构不再是星状，而是链式的，即一个slave可以是下一个的slave的master，可以减轻master的压力。其余特性和一主二从类似。如A-->B-->C，A是master，B是A的从机，B又是C的master，缺点就是当B挂掉后C不能同步A的数据。

反客为主

用slave no one......命令

当master挂掉以后，其后的slave变为master，其他slave

以上三种都需要手动干预主机的选择，非常的不方便，可以使用哨兵模式去解决。

哨兵模式

反客为主自动版，后台能够监控主机是否故障，如果故障的话可以通过投票方式选出新主机。

配置哨兵

在sentinel.conf里修改

sentinel monitor mymaster 127.0.0.1 6380 1

其中1表示至少1个哨兵同意才进行迁移

因为我从机也配置了密码，所以在哨兵模式核心配置文件中加入密码，主机与从机的密码需保持一致，不然会出现主机无法切换和哨兵检测不到从机的情况。

sentinel auth-pass mymaster ICURX0228xb?

启动哨兵

redis-sentinel msdemo/sentinel.conf

到这基本的配置就完成了，可以简单测试下，将6380主机shutdown，可以从哨兵看到，将6381选为新的主机，并且原主机6380作为其从机（只不过挂掉了）

 再看6381，此时role已经变为master，并且从机连接数量为1（6382）：

 当我们将6380重新上线之后发现已经变为6381的从机了。

 复制延迟

由于所有写都在master上，然后同步到slave，所以会有一定延迟，slave越多这个问题越严重

选举策略

优先级 > 偏移量 > runid

 主机挂掉以后该选哪个从机为新主机呢？

在redis.conf中有这么一个属性,值越小优先级越高

replica-priority 100   //老版本叫slave-priority

如果优先级一样，则选择偏移量最大的（和主机同步数据最多的）

如果偏移量也一样，则选择runid最小的服务（每个redis启动时都会生成一个40位的随机的runid）

当选出新的master收，sentinel会向原主服务的从机发送【slaveof 新主机】命令。当下线的从机上线后，sentinel会向从机发送【slaveof 新主机】，让其成为新主机的从主机。