目录：
1. 集群概念
2. 主从复制
3. 哨兵模式 sentinel
1 集群概念
所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。
1.1 使用redis集群的必要性
（1）单个redis存在不稳定性。当redis服务宕机了，就没有可用的服务了。
（2）单个redis的读写能力是有限的。
1.2 如何学习redis集群
（1）redis集群中，每一个redis称之为一个节点。
（2）redis集群中，有两种类型的节点：主节点(master)、从节点(slave)。
（3）redis集群 ，是基于redis主从复制实现。
所以，学习redis集群，就是从学习redis主从复制模型开始的
2 主从复制
2.1 概念
redis主从中，仅有一个主节点（master），其余是从节点（slave）
master 可读可写，slave 只能读
2.2 主从实现
安装 redis
$ wget http://download.redis.io/releases/redis-2.8.3.tar.gz $ tar xzf redis-2.8.3.tar.gz $ cd redis-2.8.3 $ make $ sudo make install $ redis-server redis.conf
实现过程
| 主节点端口 master | 6381 |
| 从节点端口 slave | 6382,6383 |
新建目录 /usr/local/redis/master-slave，复制 redis.conf 文件到该目录下并改名
编辑reids-6381.conf ，把默认端口号修改为 6381
编辑reids-6382.conf ，把默认端口号修改为 6382 并添加主节点IP端口 slaveof 127.0.0.1 6381
编辑reids-6383.conf ，把默认端口号修改为 6383 并添加主节点IP端口 slaveof 127.0.0.1 6381
，
启动redis主从节点，测试主从复制结果
1 cd /usr/local/redis/master-slave 2 redis-server redis-6381.conf 3 redis-server redis-6382.conf 4 redis-server redis-6383.conf 5 cd /root/redis-2.8.3/src 6 redis-cli -p 6381 7 set user:name china 8 get user:name 9 redis-cli -p 6382 10 get user:name 11 redis-cli -p 6383 12 get user:name
下图演示了 slave节点 进行写入操作，验证了本文2.1节 所说的：slave 只能读取
3 哨兵模式 Sentinel
3.1为什么需要哨兵模式
无哨兵模式的情况：当master节点宕机了，整个集群就没有可写的节点了。
有哨兵模式的情况：当master节点宕机了，slave节点会选取其中一个slave改变为master
3.2 哨兵的任务
Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会进行选举，将其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
监控（Monitoring）
（1）Sentinel可以监控任意多个Master和该Master下的Slaves。（即多个主从模式）
（2）同一个哨兵下的、不同主从模型，彼此之间相互独立。
（3）Sentinel会不断检查Master和Slaves是否正常。
自动故障切换（Automatic failover）
监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel网络，互相通信并交换彼此关于被监视服务器的信息。下图中，三个监控s1的Sentinel，自动组成Sentinel网络结构。
疑问：为什么要使用sentinel网络呢？
答：当只有一个sentinel的时候，如果这个sentinel挂掉了，那么就无法实现自动故障切换了。
在sentinel网络中，只要还有一个sentinel活着，就可以实现故障切换。
故障切换的过程
（1）投票（半数原则）
当任何一个Sentinel发现被监控的Master下线时，会通知其它的Sentinel开会，投票确定该Master是否下线（半数以上，所以sentinel通常配奇数个）。
（2）选举
当Sentinel确定Master下线后，会在所有的Slaves中，选举一个新的节点，升级成Master节点。
其它Slaves节点，转为该节点的从节点。
（3）原Master重新上线
当原Master节点重新上线后，自动转为当前Master节点的从节点。
3.3 哨兵实现
前提：已经存在一个正在运行的主从模式。
另外，配置三个Sentinel实例，监控同一个Master节点。
配置Sentinel
新建目录 /usr/local/redis/sentinels，复制 sentinel.conf 文件到该目录下并改名
依次编辑这3个文件，每个文件修改两处内容：
依次启动 sentinel-2637*.conf
redis-sentinel sentinel-26371.conf redis-sentinel sentinel-26372.conf redis-sentinel sentinel-26373.conf
测试
master(6381)节点set成功，slave(6382,6383)节点set异常
查找master(6381)节点进程编号，然后kill掉
ps -ef |grep redis kill -9 1221 ps -ef |grep redis
slave节点（6382,6383）进行set操作。
下图表明 6382 set 成功，6383 set 异常 （如果你两个set都异常，请等二分钟，因为在你kill掉原来的master时候到现在这个时间段，哨兵还没有从原来的slave选举一个新的master）
启动6381（原来的master，刚才被手动kill掉了），进行set操作异常。
原来的master变成了slave。
第一轮：master（6381），slave（6382，6383）
.......6381挂了，哨兵从slave选举6382为新master
.......6381启动，6381属于slave
新一轮：master（6382），slave（6381，6383）
哨兵模式解决了redis主从复制 当主挂掉后无法继续往缓存写入的问题