目录:
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主从复制 当主挂掉后无法继续往缓存写入的问题