项目中通常会需要若干台Redis服务器来协同担当起内存数据库的工作，在redis的部署方案上要考虑下面几点：
结构上，单个 Redis 服务器会发生单点故障，而且一台服务器需要承受所有的请求负载。 这就需要为数据生成多个副本并分配在不同的服务器上；
容量上，单个 Redis 服务器的内存非常容易成为存储瓶颈，所以需要进行数据分片。
同时拥有多个 Redis 服务器后就会面临如何管理集群的问题，包括如何增加节点、故障恢复等操作。
本次实践的目标就是从高可用的角度，针对redis的集群和哨兵方案的部署实践。
一、目标
使用高可用的redis集群和哨兵方案，进行部署。
模拟当主redis宕机的情况下，redis服务能够正常使用。
当宕机故障恢复后，数据和服务可以正常使用。
二、部署环境和方案
主Redis ： centos6.5 192.168.136.144 后面用144主机来说明
从Redis： centos6.5 192.168.136.155 后面用155主机来说明
哨兵： 哨兵在144主机上部署2个，在155主机上部署1个。
采用 redis版本为 redis-3.2.3.tar.gz
2.1 整体部署图如下：
2.2 方案描述：
Redis缓存服务采用Master-Slaver模式，Master节点负责读写操作，Slaver节点负责从Master节点上做Replication的复制。Master和Slaver节点分别部署在不同主机上，组成一组Redis服务。Redis组内采用Redis官方提供的Sentinel（哨兵）机制做failover，通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决。
在Redis现在的版本中，都融合了Sentine服务，基于Sentinel的主从切换方案，Sentinel用于管理多个Redis服务器实例，主要负责三个方面的任务：
1. 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。每个sentinel会向其它sentinal、master、slave定时发送消息，以确认对方是否“活”着，如果发现对方在指定时间（可配置）内未回应，则暂时认为对方已挂（所谓的“主观认为宕机” Subjective Down，简称SDOWN）。若“哨兵群”中的多数sentinel，都报告某一master没响应，系统才认为该master"彻底死亡"(即：客观上的真正down机，Objective Down，简称ODOWN)。
2. 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3. 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会通过一定的vote算法，从失效主服务器的其中一个从服务器升级为新的主服务器， 并自动修改相关配置，让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。当失效的Master恢复后，Redis Sentinel会自动识别，将Master自动转换为Slave并完成数据同步。通过Redis Sentinel可以实现Redis零手工干预并且短时间内进行M-S切换，减少业务影响时间。
2.3 缓存主要设置
持久化策略：Master采用快照方式生成RDB文件，Slave采用快照方式生成RDB文件的同时利用增加AOF策略。
虚拟内存：关闭
最大内存：60%~80%物理内存
2.4 队列主要设置
持久化策略：关闭
虚拟内存：关闭
最大内存：60%~80%物理内存
三、部署步骤
3.1 主Redis安装和配置
3.1.1 主Redis的安装
Redis的安装，可以参考博文实践（一）的内容进行。部署完成后，我们需要进行集群的配置
3.1.2 主Redis的配置
进入/usr/local/etc/redis 目录，我们可以查看到有下列文件
[root@cwqsolo redis]# ls -ltr
total 52
-rw-r--r-- 1 root root 46696 Nov 9 19:10 redis.conf
-rw-r--r-- 1 root root 95 Nov 12 04:14 dump.rdb
[root@cwqsolo redis]# 现在，我们要修改配置文件，使之可以支持集群
在这个目录下，创建一个Master使用的配置目录
mkdir 6379
cp ./redis.conf ./6379/redis6379.conf
然后，我们要修改redis6379.conf的内容：
daemonize yes
pidfile /var/run/redis6379.pid
port 6379
#根据所在主机ip更改
bind 192.168.136.144
logfile /home/lteapp/redis/6379/redis.log
dbfilename dump.rdb
#dir是dump.rdb文件存放的路径，存放redis内存数据的快照
dir /home/lteapp/redis/6379/
repl-ping-slave-period 10
repl-timeout 120
client-output-buffer-limit slave 512mb 128mb 120
Redis在主从复制时，需要fork子进程来进行操作，如果你的应用堆积了很大数据在内存中，那么就需要针对这个子进程申请相应的内存空间，此时会受到操作系统的限制。通过更改系统配置文件/etc/sysctl.conf的vm.overcommit_memory=1以永久生效。
vi /etc/sysctl.conf
修改
vm.overcommit_memory=1
3.1.3 验证一下redis master 已经成功安装
启动方式: redis-server /usr/local/etc/redis/6379/redis6379.conf
注意启动后，可以通过redis-cli进行控制和交互。
停止方式：redis-cli -h 192.168.136.144 -p 6379
进入后，输入shutdown
注意这里需要添加-h参数，如果不添加此参数，会报告如下异常：
Could not connect to Redis at 127.0.0.1:6379: Connection refused
原因就是在conf文件中，我们配置 bind 参数
info 命令可以查看redis的完整信息。
至此，redis单节点安装完毕。
为了适应集群的安装
1） 首先修改redis conf配置，使之适应
pidfile /var/run/redis-M-6379.pid
##日志刷新策略（Master禁用）
#save 900 1
#save 300 10
#save 60 10000
#镜像备份文件的文件名
dbfilename redis-35-M_dump.rdb
##启用增量（Master禁用）
appendonly no
##slaveof no one
slave-read-only yes
3.1.2 Redis slave 安装和配置
首先和上面安装Redis Master 一样，进行安装，以及各个目录建立，可以拷贝144上Mater的配置文件。
我们这里假设已经拷贝完成，那么我们需要修改下面信息以满足slave的设置需要。
port 6379
##Redis 默认pid 文件位置redis.pid,当运行多个 redis 服务时，需要指定不同的 pid 文件和端口
pidfile redis-S-6379.pid
##日志刷新策略（Master禁用）
save 900 1
save 300 10
save 60 10000
#镜像备份文件的文件名
dbfilename redis-S-dump.rdb
##启用增量（Master禁用）
appendonly yes
##设置该数据库为其他数据库的从数据库,主库无需设置
slaveof 192.168.136.144 6379
##-----------其他配置和master保持一致-----------##
3.1.3 Redis Sentinel 安装配置
先在redis根目录下创建conf子目录，把默认的sentinel.conf文件复制进来，重命名为sentinel-16379.conf，并修改以下配置信息：
进入 /home/nmc/dev/redis/redis-3.2.3，然后执行cp sentinel.conf /usr/local/etc/redis/6379命令
接下来，我们进入 /usr/local/etc/redis/6379 目录将哨兵配置文件改名，mv sentinel.conf sentinel-1-16379.conf
修改内容如下：
##sentinel-16379.conf
##sentinel实例之间的通讯端口
port 16379
##指定工作目录
dir /home/nmc/dev/redis/redis6379/sentinel-1
##显示监控master节点10.45.47.35，master节点使用端口6379，最后一个数字表示投票需要的"最少法定人数"，比如有10个sentinal哨兵都在监控某一个master节点，如果需要至少6个哨兵发现master挂掉后，才认为master真正down掉，那么这里就配置为6，最小配置1台master，1台slave，在二个机器上都启动sentinal的情况下，哨兵数只有2个，如果一台机器物理挂掉，只剩一个sentinal能发现该问题，所以这里配置成1，至于mymaster只是一个名字，可以随便起，但要保证下面使用同一个名字
sentinel monitor mymaster 192.168.136.144 6379 1
##表示如果10s内mymaster没响应，就认为SDOWN
sentinel down-after-milliseconds mymaster 10000
##表示如果master重新选出来后，其它slave节点能同时并行从新master同步缓存的台数有多少个，显然该值越大，所有slave节点完成同步切换的整体速度越快，但如果此时正好有人在访问这些slave，可能造成读取失败，影响面会更广。最保定的设置为1，只同一时间，只能有一台干这件事，这样其它slave还能继续服务，但是所有slave全部完成缓存更新同步的进程将变慢。
sentinel parallel-syncs mymaster 1
##表示如果15秒后,mysater仍没活过来，则启动failover，从剩下的slave中选一个升级为master
sentinel failover-timeout mymaster 15000
##当failover时，指定一个“通知”脚本用来告知系统管理员，当前集群的情况。脚本被允许执行的最大时间为60秒，如果超时，脚本将会被终止(KILL) 脚本执行的结果： 1:稍后重试，最大重试次数为10; 2: 执行结束，无需重试
部署完Sentinel-1 后，我们在144主机上部署Sentinel-2
cp /usr/local/etc/redis/6379/sentinel-1-16379.conf sentinel-2-26379.conf
修改sentinel-2-26379.conf 中如下内容
port 26379
dir /home/nmc/dev/redis/redis6379/sentinel-2
接着，我们在155主机上部署Sentinel-3
进入/usr/local/etc/redis/6379/目录，执行如下命令
scp root@192.168.136.144:/usr/local/etc/redis/6379/sentinel-1-16379.conf .
将远程144机器上的文件拷贝到本地
mv sentinel-1-16379.conf sentinel-3-16379.conf
无需修改内容
在155主机上，要建立conf文件中的目录
mkdir /home/nmc/dev/redis/redis6379/sentinel-2
3.1.4 启动验证：
144、155主机上执行下面的启动命令：
redis-server /usr/local/etc/redis/6379/redis6379.conf 启动sentinel
144机器上，启动2个哨兵
nohup redis-sentinel /usr/local/etc/redis/6379/sentinel-1-16379.conf > /home/nmc/dev/redis/redis6379/sentinel-1/redis-sentinel-1.log 2>&1 &
nohup redis-sentinel /usr/local/etc/redis/6379/sentinel-2-26379.conf > /home/nmc/dev/redis/redis6379/sentinel-2/redis-sentinel-2.log 2>&1 & 155上启动1个哨兵
nohup redis-sentinel /usr/local/etc/redis/6379/sentinel-3-16379.conf > /home/nmc/dev/redis/redis6379/sentinel-3/redis-sentinel-3.log 2>&1 &
(对于一组Redis master和slave上都启用sentinel，及另外一台机器上再额外启动一个，即最终有三个哨兵)
redis-cli -h 192.168.136.144 -p 16379 sentinel masters 可通过该命令查看当前的master节点情况
redis-cli -p 16379 info 可通过该命令查看master地址，有几个slave，有几个监控
说明：这里第一次操作没有成功，而且杀掉master后，并没有选择出来新的master。检查后，发现配置文件错误，需要重新修改配置文件，redis 实例中的conf 文件，要确定 protected-mode no ，sentinel的conf文件中，也要手工加上 protected-mode no
启动完成后，我们可以查看redis实例的情况
144 主机上，查看info显示redis为 master
155主机，显示为slave
我们在155 可以查询key value，但是无法设置值
四、高可用验证
验证场景：
1） 我们先杀掉master，观察哨兵日志，是否进行了选举，重新选slave为master
通过 redis-cli -h 192.168.136.144 -p 6379 shutdown 命令杀掉 144 master
2）登录155，查看info信息，并在155 设置新的 key value：（color2 green） （color3 green）。
3）重启144， 观察是否变为slave
而且可以获取前面进程失效时， 155 设置的新的key和value
4）杀掉155的master，观察144是否重新变成了master
说明只要2台redis 不同时故障，redis的高可用是可以达到的。
