Redis的三种集群模式
一、简介
1、为什么要用redis? 大并发的情况下,所有的请求直接访问数据库,数据库会出现连接异常。这个时候,就需要使用Redis做一个缓冲操作,让请求先访问到Redis,而不是直接访问数据库。 2、为什么要用集群? 集群,就是通过添加服务器的数量,提供相同的服务,从而使服务器达到一个稳定、高效的状态。 3、为什么要使用Redis集群? 因为单台的Redis服务器一旦宕机,就无法正常的提供服务了; 单台Redis服务器的读写性能有限,利用集群可以提高读写能力 总结起来使用集群的原因可以归为提高服务器的稳定性和提高读写能力
部署redis脚本
ip=10.48.14.50 password=Lyt@12345 pidpath=/usr/local/redis/logs/redis.pid logpath=/usr/local/redis/logs/redis.log tar -xf redis-6.2.4.tar.gz cd redis-6.2.4 make MALLOC=libc cd src make install PREFIX=/usr/local/redis mkdir /usr/local/redis/{etc,logs} cp /root/install-package/redis-6.2.4/redis.conf /usr/local/redis/etc sed -i "/bind 127.0.0.1 -::1/s/127.0.0.1 -::1/$ip/g" /usr/local/redis/etc/redis.conf sed -i "/daemonize no/s/no/yes/g" /usr/local/redis/etc/redis.conf sed -i "/appendonly no/s/no/yes/g" /usr/local/redis/etc/redis.conf sed -i "/pidfile /c pidfile $pidpath" /usr/local/redis/etc/redis.conf sed -i "/logfile /c logfile $logpath" /usr/local/redis/etc/redis.conf #sed -i "$a requirepass $password" /usr/local/redis/etc/redis.conf sed -i "s|# requirepass |requirepass $password|" /usr/local/redis/etc/redis.conf cat >/usr/lib/systemd/system/redis.service <<EOF [Unit] Description=redis-server After=network.target [Service] Type=forking ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf ExecStop=/usr/local/redis/bin/./redis-cli -h $ip -p 6379 -a $password shutdown PrivateTmp=true [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl start redis systemctl status redis systemctl enable redis
二、Redis主从复制
2.1 主从复制优缺点
优点:读写分离,将Redis读操作分摊到多个节点,大大提高redis服务器的并发量
缺点:不支持容错,master宕机后没有可写节点,可能会数据丢失,较难支持扩容
2.2 主从同步数据
全量同步:发生在slave初始阶段,slave需要将master的所有数据复制 过程:1、slave向master发送sync(同步命令) 2、master执行bgsave命令生成数据库快照,保存到RDB文件,然后给所有slave节点发送 3、slave收到RDB文件后,丢弃旧数据,载入RBD快照文件 4、master向slave发送缓存区中的写命令 5、slave接收写命令,并执行 增量同步:发生在slave初始完成,master每执行一条写命令,就向slave发送一次写命令
2.3 搭建redis主从集群
2.3.1 准备服务器(最少俩台,都安装redis) 192.168.50.10 master 192.168.50.11 slave 192.168.50.13 slave 2.3.2 修改redis配置文件 master redis.conf bind 192.168.50.10 #绑定地址 port 6379 daemonize yes #后台启动 protected-mode yes #打开保护模式 appendonly yes #开启AOF持久化存储 requirepass 123 #启用密码认证 pidfile /usr/local/redis-6379/logs/redis-6379.pid logfile /usr/local/redis-6379/logs/redis.log dir masterauto 123 slave1 redis.conf bind 192.168.50.11 #绑定地址 port 6379 daemonize yes #后台启动 protected-mode yes #打开保护模式 appendonly yes #开启AOF持久化存储 requirepass 123 #启用密码认证 pidfile /usr/local/redis-6379/logs/redis-6379.pid logfile /usr/local/redis-6379/logs/redis.log dir masterauto 123 #master节点密码 replicaof 192.168.50.10 6379 #定义master信息 slave2 redis.conf bind 192.168.50.13 #绑定地址 port 6379 daemonize yes #后台启动 protected-mode yes #打开保护模式 appendonly yes #开启AOF持久化存储 requirepass 123 #启用密码认证 pidfile /usr/local/redis-6379/logs/redis-6379.pid logfile /usr/local/redis-6379/logs/redis.log dir masterauto 123 #master节点密码 replicaof 192.168.50.10 6379 #定义master信息 注:当bind和requirepass都注释时,protected-mode需要设置为no;开启任意一个都需要设置成yes; bind的是Redis服务器的网卡接口,而非可以访问redis服务器的IP;如通过命令 hostname -I 查看本机的网卡接口 192.168.0.1,192.168.1.254,那么bind设置如下: bind 127.0.0.1 192.168.0.1 192.168.1.254 slaveof 192.168.50.11 6000 旧版redis定义master信息(从5.0.0版本开始slaveof被启用) replicaof 192.168.50.11 6000 新版redis定义master信息
2.3.3 重启redis,让配置生效
systemctl restart redis
2.4 验证
redis-cli -h 192.168.50.10 -a 123 -p 6379 #登录redis客户端 -h:绑定IP -a:密码认证 -p:端口
info replication #查看redis信息
set mykey 111 进入slave的客户端查看key值进行验证:
get mykey
#会发现master和slave数据是同步的
三、哨兵模式(sentinel)
3.1 哨兵模式工作原理
Sentinel哨兵模式:管理多个redis服务器,执行三个任务: 监控:监控主从服务器状态 提醒:通过API向管理员发送通知 自动故障迁移: 投票:确定master是否下线 (半数原则,至少3个sentinel节点) 选举:sentiner集群选举出sentiner leader,sentinel leader在redis从节点中选举一个节点作为主节点 选举master依据: Slave-priority:(优先级)最大 复制偏移量:数据写入量最大 Runid:(启动redis生成随机的rundi作为标识)最小
优点:支持故障切换,提高了redis服务的稳定性
3.2 搭建redis 哨兵模式
3.2.1 准备服务器(在主从模式的基础上操作) 分别在三台服务器上新建目录: mkdir /usr/local/redis-6379/s1/ mkdir /usr/local/redis-6379/s2/ mkdir /usr/local/redis-6379/s3/ 将源码包redis-6.2.4下sentinel.conf复制到新建的目录里: cp redis-6.2.4/sentinel.conf /usr/local/redis-6379/s1/ cp redis-6.2.4/sentinel.conf /usr/local/redis-6379/s2/ cp redis-6.2.4/sentinel.conf /usr/local/redis-6379/s3/ 3.2.2 修改配置文件(sentinel.conf) s1 sentinel.conf bind 192.168.50.10 port 26379 #哨兵s1的服务端口 daemonize yes #后台启动 protected-mode yes #打开保护模式 pidfile /usr/local/redis-6379/s1/redis-sentinel.pid logfile /usr/local/redis-6379/s1/redis-sentinel.log dir /usr/local/redis-6379/s1/ sentinel monitor mymaster 192.168.50.10 6379 2 sentinel auth-pass mymaster 123 s2 sentinel.conf bind 192.168.50.11 port 26379 #哨兵s1的服务端口 daemonize yes #后台启动 protected-mode yes #打开保护模式 pidfile /usr/local/redis-6379/s2/redis-sentinel.pid logfile /usr/local/redis-6379/s2/redis-sentinel.log dir /usr/local/redis-6379/s2/ sentinel monitor mymaster 192.168.50.10 6379 2 sentinel auth-pass mymaster 123 s3 sentinel.conf bind 192.168.50.13 port 26379 #哨兵s1的服务端口 daemonize yes #后台启动 protected-mode yes #打开保护模式 pidfile /usr/local/redis-6379/s3/redis-sentinel.pid logfile /usr/local/redis-6379/s3/redis-sentinel.log dir /usr/local/redis-6379/s3/ sentinel monitor mymaster 192.168.50.10 6379 2 sentinel auth-pass mymaster 123 #解释 sentinel monitor mymaster 192.168.50.10 6379 2 意思是告诉哨兵去监听地址为192.168.50.10:6379的一个master,在投票过程中超过2个哨兵同意Master下线时,Master即视为宕机状态 这里的mymaster是master-name 可以自定义 数字"2"是指明当有2个哨兵认为master挂了,才算真的挂了,这个数字要根据有多少节点来算 3.2.3 重启redis,并加载哨兵 systemctl restart redis 分别通过s1,s2,s3中的配置问起开启三个哨兵(由于监视的为同一个Master,三个哨兵会自动组成哨兵网络) redis-sentinel /usr/local/redis-6379/s1/redis-sentinel redis-sentinel /usr/local/redis-6379/s2/redis-sentinel redis-sentinel /usr/local/redis-6379/s3/redis-sentinel
3.3 测试
断开Master (192.168.50.10 6379) 查看哨兵的选举过程 Master重新上线(192.168.50.10 6379) 查看哨兵的选举过程
#故障切换成功
四、分片集群
4.1 分片集群原理:哈希slot(分库分表)
1、对象保存到Redis之前先经过CRC16哈希到一个指定的Node上,例如Object4最终Hash到了Node1上。 2、将整个数据库分为16384个槽位,所有的数据都是这些slot的一个,每个Node被平均分配了一个Slot段,对应着0-16384,Slot不能重复也不能缺失,否则会导致对象重复存储或无法存储。 3、Node之间也互相监听,一旦有Node退出或者加入,会按照Slot为单位做数据的迁移。例如Node1如果掉线了,0-5640这些Slot将会平均分摊到Node2和Node3上,由于Node2和Node3本身维护的Slot还会在自己身上不会被重新分配,所以迁移过程中不会影响到5641-16384Slot段的使用。
4.2 分片集群优缺点
优点:将Redis写操作分摊到多个节点,提高写的并发能力,扩容简单
缺点:每个node承担着互相监听、高并发数据写入、高并发数据读出,工作任务繁重
主从+哈希slot结合
主从跟哈希slot的优缺点互补,结合起来就是Redis集群的终极形态,先哈希slot分逻辑节点,每个逻辑节点内部是主从
作者:等风来~~
本博客所有文章仅用于学习、研究和交流目的,欢迎转载。
如果觉得文章写得不错,或者帮助到您了,请点个赞。
如果文章有写的不足的地方,请你一定要指出,因为这样不光是对我写文章的一种促进,也是一份对后面看此文章的人的责任。谢谢。