1：实验环境
测试环境两台：
master：172.16.16.34
slave：172.16.16.35
redis版本：redis3.2
要搭建的环境是，redis简单主从复制
2：安装redis
tar xzf redis-3.2.8.tar.gz cd redis-3.2.8 yum install gcc make
注意我们使用的是redis3.2.8的版本，这是目前最稳定也是最新的redis版本了。下面我们看一下简单配置
3：配置启动redis
先看一下我主库的配置文件（172.16.16.34）
#bind 127.0.0.1 # 绑定的主机地址 protected-mode no # 是否开启保护模式，开启该参数后，redis只会本地进行访问 port 6379 timeout 300 # 当客户端闲置多长时间后关闭连接 daemonize yes # 是否以守护进程的模式运行 pidfile /home/redis/tmp/redis_6379.pid loglevel notice # 日志级别，最好是warning logfile /home/redis/log/redis_6379.log databases 16 save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes # 在出现错误的时候，是否要停止保存 rdbcompression yes # 使用压缩rdb文件 rdbchecksum yes # 是否校验rdb文件的名称 dbfilename dump.rdb dir /home/redis/data # 数据库目录，数据库的写入会在这个目录 slave-serve-stale-data yes #主从失去联系以后，继续相应客户端的请求 #slave-read-only yes # yes开启从库只读 repl-diskless-sync no # 是否使用socket方式复制数据，采用disk的方式 repl-diskless-sync-delay 5 # diskless复制的延迟时间，默认值是5，可以不设置 repl-disable-tcp-nodelay no #此设置可减少延迟 slave-priority 100 # 设置优先级，最低的优先级会优先称为主节点 appendonly no #不使用appendonly来进行持久化操作 #appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite no # auto-aof-rewrite-percentage 100 #开始重写日志 auto-aof-rewrite-min-size 64mb lua-time-limit 5000 #最长时间设置，默认为毫秒 slowlog-log-slower-than 10000 #慢查询的时间 slowlog-max-len 128 latency-monitor-threshold 0 #关闭监视器 requirepass maxiangqianredis
然后启动主库的redis：
/home/maxiangqian/redis-3.2.8/src/redis-server /home/redis/redis.conf
这里需要注意的一点就是后面的注释都要去掉，因为redis会继续往后读取，#并不适用除了首行以上。
下面配置从库redis并且启动从库（172.16.16.35）：
port 6379 timeout 300 daemonize yes pidfile /home/redis/tmp/redis_6379.pid loglevel notice logfile /home/redis/log/redis_6379.log databases 16 save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /home/redis/data slave-serve-stale-data yes #slave-read-only yes # yes开启从库只读 repl-diskless-sync no repl-diskless-sync-delay 5 repl-disable-tcp-nodelay no slave-priority 100 appendonly no #appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb lua-time-limit 5000 slowlog-log-slower-than 10000 slowlog-max-len 128 latency-monitor-threshold 0 requirepass maxiangqianredis slaveof 172.16.16.34 6379 masterauth maxiangqianredis
启动redis从库
/home/maxiangqian/redis-3.2.8/src/redis-server /home/redis/redis.conf
我们注意就是从库的配置的话比主库是多了最后两行，指定主库，指定主库的认证方式
另外我们也可以在从库加上slave-read-only yes参数来控制从库是否是只能为只读。
然后同样方法启动一个6380的从库
4：查看redis主从同步是否成功
主库执行如下操作
[root@localhost redis]# /home/maxiangqian/redis-3.2.8/src/redis-cli 127.0.0.1:6379> AUTH maxiangqianredis OK 127.0.0.1:6379> set name maxiangqian OK
从库验证是否配置成功：
[root@mxqmongodb2 redis]# /home/maxiangqian/redis-3.2.8/src/redis-cli 127.0.0.1:6379> get name 127.0.0.1:6379> AUTH maxiangqianredis OK 127.0.0.1:6379> get name "maxiangqian"
我们可以看到，slave已经同步了master的数据。简单的主从搭建也就完成了。
5：现在主从配置成功了，但是万一主库down掉，我们是并不能主动进行切换的，所以我们要做高可用方案，我们使用redis官方推荐的Redis-Sentinel，关于这个介绍，可以网上搜下，介绍还是很多的。不过我们还是简单介绍一下Redis-Sentinel吧。
Redis-Sentinel的主要作用：
（1）监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
（2）提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
（3）自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
我们看到了Redis-Sentinel的功能以后就看一下怎么启动Redis-Sentinel，官方给的是有两种启动方式：
edis-sentinel /path/to/sentinel.conf redis-server /path/to/sentinel.conf --sentinel
两种启动方式都是可以的。下面看一下我们要怎么去配置这个Redis-Sentinel：
最基本的配置如下：
port 26379 logfile "/home/Sentinel/log/sentinel_263797.log" daemonize yes sentinel monitor localhost 172.16.16.34 6379 2 sentinel down-after-milliseconds localhost 60000 sentinel failover-timeout localhost 180000 sentinel parallel-syncs localhost 1 sentinel auth-pass localhost maxiangqianredis #sentinel notification-script <master-name> <script-path>
最后一行代码主要是用来发生切换之后执行的一个自定义脚本：如发邮件、vip切换等。比较方便我们操作。再看一下Redis-Sentinel的基本操作
PING ：返回 PONG 。 SENTINEL masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态。 SENTINEL slaves ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态。 SENTINEL get-master-addr-by-name ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号。 SENTINEL reset ： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel 。 SENTINEL failover ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移 （不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。
下面开始配置Redis-Sentinel的监控：
[root@mxqmongodb2 home]# mkdir Sentinel [root@mxqmongodb2 home]# cd Sentinel/ [root@mxqmongodb2 Sentinel]# mkdir data log tmp 启动： /home/maxiangqian/redis-3.2.8/src/redis-server /home/Sentinel/sentinel.conf --sentinel
查看一下啊主库信息：
SENTINEL masters
SENTINEL slaves localhost
可以看到，master信息和两个从库的信息已经打印出来了。已经检测成功了。
同样配置文件在35上在启动一个 sentinel。
127.0.0.1:26379> info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=localhost,status=ok,address=172.16.16.34:6379,slaves=2,sentinels=4
我们已经看到已经启动了主从以及sentinel HA，下面我们测试一下故障转移
6：测试故障转移
127.0.0.1:26379> sentinel failover localhost OK 下面我们看一下redis强制故障转移以后的信息 127.0.0.1:26379> info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=localhost,status=ok,address=172.16.16.35:6379,slaves=2,sentinels=2
可以看到现在35:6379已经转移称为了主节点。
我们进入我们的sentinel的日志看一下failover的一个过程
29042:X 28 Apr 10:55:14.340 # +try-failover master localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:14.394 # +vote-for-leader 51fc16eb8e0bf950a3f3ada8c1eb9d70145c9ffb 1 29042:X 28 Apr 10:55:14.395 # +elected-leader master localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:14.395 # +failover-state-select-slave master localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:14.457 # +selected-slave slave 172.16.16.35:6379 172.16.16.35 6379 @ localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:14.457 * +failover-state-send-slaveof-noone slave 172.16.16.35:6379 172.16.16.35 6379 @ localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:14.510 * +failover-state-wait-promotion slave 172.16.16.35:6379 172.16.16.35 6379 @ localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:15.436 # +promoted-slave slave 172.16.16.35:6379 172.16.16.35 6379 @ localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:15.436 # +failover-state-reconf-slaves master localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:15.507 * +slave-reconf-sent slave 172.16.16.35:6380 172.16.16.35 6380 @ localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:16.465 * +slave-reconf-inprog slave 172.16.16.35:6380 172.16.16.35 6380 @ localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:16.466 * +slave-reconf-done slave 172.16.16.35:6380 172.16.16.35 6380 @ localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:16.540 # +failover-end master localhost 172.16.16.34 6379 29042:X 28 Apr 10:55:16.540 # +switch-master localhost 172.16.16.34 6379 172.16.16.35 6379 29042:X 28 Apr 10:55:16.541 * +slave slave 172.16.16.35:6380 172.16.16.35 6380 @ localhost 172.16.16.35 6379 29042:X 28 Apr 10:55:16.541 * +slave slave 172.16.16.34:6379 172.16.16.34 6379 @ localhost 172.16.16.35 6379
过程如下：
（1）尝试DOWN掉主节点redis172.16.16.34 6379
（2）选取一个从节点作为DOWN后的主节点172.16.16.35:6379
（3）重写配置文件
查看配置文件发现，主库重新指定为
slaveof 172.16.16.35 6379
（4）主库DOWN结束，新节点172.16.16.35:6379成为了主节点，然后另外两个节点称为主节点的从节点。
=至此完毕，本文是自己测试学习结果，如果你感觉此文对你有帮助，请帮忙点一下推荐。这将鼓励我继续写下去。