平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“Redis主从配置(Sentinel和Failover)的做法实现方法”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。
1. 结构图
设计结构图如下所示，三台物理机子；
192.168.0.101为Master，其余2台为Slave。
2. Master的redis.conf设置
# 开启守护模式
daemonize yes
# 设置密码
requirepass redis
# 指定数据存储目录
dir ./
# 每秒一次aof写
appendfsync everysec
# 打开aof持久化
appendonly yes
#设置Master的密码（如果Master有密码的话）
masterauth redis
#3.2之后新加特性，在没有配置密码和bind是启用保护机制
protected-mode no
#注释掉bind
#bind 127.0.0.1
3. Slave的redis.conf设置
# 开启守护模式
daemonize yes
# 设置密码
requirepass redis
# 指定数据存储目录
dir ./
# 每秒一次aof写
appendfsync everysec
# 打开aof持久化
appendonly yes
# 指定所属的主机
slaveof 192.168.0.101 6379
#设置Master的密码（如果Master有密码的话）
masterauth redis
# 指定从机"只读"
slave-read-only yes
#3.2之后新加特性，在没有配置密码和bind是启用保护机制
protected-mode no
#注释掉bind
#bind 127.0.0.1
4. 启动redis
在这个场景下，这时候能够分别启动3台redis，在master中设置数据，会同步到其它2台slave中。
5. Sentinel.conf设置
# sentinel通讯端口
port 26379
#3.2之后新加特性，在没有配置密码和bind是启用保护机制
protected-mode no
# sentinel需要监控的master/slaver信息，格式为sentinel monitor <mastername> <masterIP> <masterPort> <quorum>
# 其中<quorum>应该小于集群中slave的个数，当失效的节点数超过了<quorum>,则认为整个体系结构失效
sentinel monitor myMaster 192.168.0.101 6379 1
# sentinel auth-pass <master-name> <password>
sentinel auth-pass myMaster redis
# master被当前sentinel实例认定为失效的间隔时间，格式为sentinel down-after-milliseconds <mastername> <milliseconds>
sentinel down-after-milliseconds myMaster 10000
# 当新master产时，同时进行“slaveof”到新master并进行同步复制的slave个数
# 在salve执行salveof同步时，将会终止客户端请求。
# 此值较大,意味着“集群”终止客户端请求的时间总和和较大。
# 此值较小,意味着“集群”在故障转移期间，多个salve向客户端提供服务时仍然使用旧数据。
sentinel parallel-syncs myMaster 1
# failover过期时间。当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failoer失败。
sentinel failover-timeout redisMaster 60000
6. 启动sentinel
分别启动3台的sentinel，会显示同步情况。
7. 注意事项
- 实际处理时，protected-mode设置默认是yes，这会导致无法连接master，需设置为no
- 若slave被关掉，这sentinel会通知各个机子
- 实际处理时，若master被关掉，那么会在剩下的slave中投票出一台作为master，系统会自动修改各自的redis.conf和sentinel.conf文件。如果原先主机重启，则会被当做是一台slave。
落到代码里，总的来说，Redis主从设置适合结合实际项目边做边理解。先抓住核心思路，再逐步补上细节和边界处理，最后效果会更稳定，也更容易复用。