Redis集群.docx
- 文档编号:28977982
- 上传时间:2023-07-20
- 格式:DOCX
- 页数:32
- 大小:1.13MB
Redis集群.docx
《Redis集群.docx》由会员分享,可在线阅读,更多相关《Redis集群.docx(32页珍藏版)》请在冰豆网上搜索。
Redis集群
1.安装Redis3.0
yum-yinstallcppbinutilsglibcglibc-kernheadersglibc-commonglibc-develgccmakegcc-c++libstdc++-develtcl
mkdir-p/usr/local/src/redis
cd/usr/local/src/redis
wgethttp:
//download.redis.io/releases/redis-3.0.2.tar.gz或者rz上传
tar-xvfredis-3.0.2.tar.gz
cdredis-3.0.2
make
报错使用makeMALLOC=libc
maketest#这个就不要执行了,需要很长时间
makeinstall
cpredis.conf/etc/
vi/etc/redis.conf
#修改如下,默认为no
daemonizeyes
#启动
redis-server/etc/redis.conf
#测试
redis-cli
2.主从复制(读写分离)
主从复制的好处有2点:
1、避免redis单点故障
2、构建读写分离架构,满足读多写少的应用场景
2.1.主从架构
2.1.1.启动实例
创建6379、6380、6381目录,分别将安装目录下的redis.conf拷贝到这三个目录下。
分别进入这三个目录,分别修改配置文件,将端口分别设置为:
6379(Master)、6380(Slave)、6381(Slave)。
同时要设置pidfile文件为不同的路径。
分别启动三个redis实例:
2.1.2.设置主从
在redis中设置主从有2种方式:
1、在redis.conf中设置slaveof
a)slaveof
2、使用redis-cli客户端连接到redis服务,执行slaveof命令
a)slaveof
第二种方式在重启后将失去主从复制关系。
查看主从信息:
INFOreplication
主:
role:
角色
connected_slaves:
从库数量
slave0:
从库信息
从:
2.1.3.测试
在主库写入数据:
在从库读取数据:
2.2.主从从架构
2.2.1.启动实例
设置主从:
设置从从:
2.2.2.测试
在主库设置数据:
在6380获取数据:
在6381获取数据:
2.3.从库只读
默认情况下redis数据库充当slave角色时是只读的不能进行写操作。
可以在配置文件中开启非只读:
slave-read-onlyno
2.4.复制的过程原理
1、当从库和主库建立MS关系后,会向主数据库发送SYNC命令;
2、主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程),并将期间接收到的写命令缓存起来;
3、当快照完成后,主Redis会将快照文件和所有缓存的写命令发送给从Redis;
4、从Redis接收到后,会载入快照文件并且执行收到的缓存的命令;
5、之后,主Redis每当接收到写命令时就会将命令发送从Redis,从而保证数据的一致;
2.5.无磁盘复制
通过前面的复制过程我们了解到,主库接收到SYNC的命令时会执行RDB过程,即使在配置文件中禁用RDB持久化也会生成,那么如果主库所在的服务器磁盘IO性能较差,那么这个复制过程就会出现瓶颈,庆幸的是,Redis在2.8.18版本开始实现了无磁盘复制功能(不过该功能还是处于试验阶段)。
原理:
Redis在与从数据库进行复制初始化时将不会将快照存储到磁盘,而是直接通过网络发送给从数据库,避免了IO性能差问题。
开启无磁盘复制:
repl-diskless-syncyes
2.6.复制架构中出现宕机情况,怎么办?
如果在主从复制架构中出现宕机的情况,需要分情况看:
1、从Redis宕机
a)这个相对而言比较简单,在Redis中从库重新启动后会自动加入到主从架构中,自动完成同步数据;
b)问题?
如果从库在断开期间,主库的变化不大,从库再次启动后,主库依然会将所有的数据做RDB操作吗?
还是增量更新?
(从库有做持久化的前提下)
i.不会的,因为在Redis2.8版本后就实现了,主从断线后恢复的情况下实现增量复制。
2、主Redis宕机
a)这个相对而言就会复杂一些,需要以下2步才能完成
i.第一步,在从数据库中执行SLAVEOFNOONE命令,断开主从关系并且提升为主库继续服务;
ii.第二步,将主库重新启动后,执行SLAVEOF命令,将其设置为其他库的从库,这时数据就能更新回来;
b)这个手动完成恢复的过程其实是比较麻烦的并且容易出错,有没有好办法解决呢?
当前有的,Redis提高的哨兵(sentinel)的功能。
3.哨兵(sentinel)
3.1.什么是哨兵
哨兵的作用就是对Redis的系统的运行情况的监控,它是一个独立进程。
它的功能有2个:
1、监控主数据库和从数据库是否运行正常;
2、主数据出现故障后自动将从数据库转化为主数据库;
3.2.原理
单个哨兵的架构:
多个哨兵的架构:
多个哨兵,不仅同时监控主从数据库,而且哨兵之间互为监控。
3.3.环境
当前处于一主多从的环境中:
3.4.配置哨兵
启动哨兵进程首先需要创建哨兵配置文件:
vimsentinel.conf
输入内容:
sentinelmonitortaotaoMaster127.0.0.163791
说明:
taotaoMaster:
监控主数据的名称,自定义即可,可以使用大小写字母和“.-_”符号
127.0.0.1:
监控的主数据库的IP
6379:
监控的主数据库的端口
1:
最低通过票数
启动哨兵进程:
redis-sentinel./sentinel.conf
由上图可以看到:
1、哨兵已经启动,它的id为9059917216012421e8e89a4aa02f15b75346d2b7
2、为master数据库添加了一个监控
3、发现了2个slave(由此可以看出,哨兵无需配置slave,只需要指定master,哨兵会自动发现slave)
3.5.从数据库宕机
kill掉2826进程后,30秒后哨兵的控制台输出:
2989:
X05Jun20:
09:
33.509#+sdownslave127.0.0.1:
6380127.0.0.16380@taotaoMaster127.0.0.16379
说明已经监控到slave宕机了,那么,如果我们将3380端口的redis实例启动后,会自动加入到主从复制吗?
2989:
X05Jun20:
13:
22.716*+rebootslave127.0.0.1:
6380127.0.0.16380@taotaoMaster127.0.0.16379
2989:
X05Jun20:
13:
22.788#-sdownslave127.0.0.1:
6380127.0.0.16380@taotaoMaster127.0.0.16379
可以看出,slave从新加入到了主从复制中。
-sdown:
说明是恢复服务。
3.6.主库宕机
哨兵控制台打印出如下信息:
2989:
X05Jun20:
16:
50.300#+sdownmastertaotaoMaster127.0.0.16379说明master服务已经宕机
2989:
X05Jun20:
16:
50.300#+odownmastertaotaoMaster127.0.0.16379#quorum1/1
2989:
X05Jun20:
16:
50.300#+new-epoch1
2989:
X05Jun20:
16:
50.300#+try-failovermastertaotaoMaster127.0.0.16379开始恢复故障
2989:
X05Jun20:
16:
50.304#+vote-for-leader9059917216012421e8e89a4aa02f15b75346d2b71投票选举哨兵leader,现在就一个哨兵所以leader就自己
2989:
X05Jun20:
16:
50.304#+elected-leadermastertaotaoMaster127.0.0.16379选中leader
2989:
X05Jun20:
16:
50.304#+failover-state-select-slavemastertaotaoMaster127.0.0.16379选中其中的一个slave当做master
2989:
X05Jun20:
16:
50.357#+selected-slaveslave127.0.0.1:
6381127.0.0.16381@taotaoMaster127.0.0.16379选中6381
2989:
X05Jun20:
16:
50.357*+failover-state-send-slaveof-nooneslave127.0.0.1:
6381127.0.0.16381@taotaoMaster127.0.0.16379发送slaveofnoone命令
2989:
X05Jun20:
16:
50.420*+failover-state-wait-promotionslave127.0.0.1:
6381127.0.0.16381@taotaoMaster127.0.0.16379等待升级master
2989:
X05Jun20:
16:
50.515#+promoted-slaveslave127.0.0.1:
6381127.0.0.16381@taotaoMaster127.0.0.16379升级6381为master
2989:
X05Jun20:
16:
50.515#+failover-state-reconf-slavesmastertaotaoMaster127.0.0.16379
2989:
X05Jun20:
16:
50.566*+slave-reconf-sentslave127.0.0.1:
6380127.0.0.16380@taotaoMaster127.0.0.16379
2989:
X05Jun20:
16:
51.333*+slave-reconf-inprogslave127.0.0.1:
6380127.0.0.16380@taotaoMaster127.0.0.16379
2989:
X05Jun20:
16:
52.382*+slave-reconf-doneslave127.0.0.1:
6380127.0.0.16380@taotaoMaster127.0.0.16379
2989:
X05Jun20:
16:
52.438#+failover-endmastertaotaoMaster127.0.0.16379故障恢复完成
2989:
X05Jun20:
16:
52.438#+switch-mastertaotaoMaster127.0.0.16379127.0.0.16381主数据库从6379转变为6381
2989:
X05Jun20:
16:
52.438*+slaveslave127.0.0.1:
6380127.0.0.16380@taotaoMaster127.0.0.16381添加6380为6381的从库
2989:
X05Jun20:
16:
52.438*+slaveslave127.0.0.1:
6379127.0.0.16379@taotaoMaster127.0.0.16381添加6379为6381的从库
2989:
X05Jun20:
17:
22.463#+sdownslave127.0.0.1:
6379127.0.0.16379@taotaoMaster127.0.0.16381发现6379已经宕机,等待6379的恢复
可以看出,目前,6381位master,拥有一个slave为6380.
接下来,我们恢复6379查看状态:
2989:
X05Jun20:
35:
32.172#-sdownslave127.0.0.1:
6379127.0.0.16379@taotaoMaster127.0.0.163816379已经恢复服务
2989:
X05Jun20:
35:
42.137*+convert-to-slaveslave127.0.0.1:
6379127.0.0.16379@taotaoMaster127.0.0.16381将6379设置为6381的slave
3.7.配置多个哨兵
vimsentinel.conf
输入内容:
sentinelmonitortaotaoMaster127.0.0.163812
sentinelmonitortaotaoMaster2127.0.0.163811
3451:
X05Jun21:
05:
56.083#+sdownmastertaotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
56.083#+odownmastertaotaoMaster2127.0.0.16381#quorum1/1
3451:
X05Jun21:
05:
56.083#+new-epoch1
3451:
X05Jun21:
05:
56.083#+try-failovermastertaotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
56.086#+vote-for-leader3f020a35c9878a12d2b44904f570dc0d4015c2ba1
3451:
X05Jun21:
05:
56.086#+elected-leadermastertaotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
56.086#+failover-state-select-slavemastertaotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
56.087#+sdownmastertaotaoMaster127.0.0.16381
3451:
X05Jun21:
05:
56.189#+selected-slaveslave127.0.0.1:
6380127.0.0.16380@taotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
56.189*+failover-state-send-slaveof-nooneslave127.0.0.1:
6380127.0.0.16380@taotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
56.252*+failover-state-wait-promotionslave127.0.0.1:
6380127.0.0.16380@taotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
57.145#+promoted-slaveslave127.0.0.1:
6380127.0.0.16380@taotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
57.145#+failover-state-reconf-slavesmastertaotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
57.234*+slave-reconf-sentslave127.0.0.1:
6379127.0.0.16379@taotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
58.149*+slave-reconf-inprogslave127.0.0.1:
6379127.0.0.16379@taotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
58.149*+slave-reconf-doneslave127.0.0.1:
6379127.0.0.16379@taotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
58.203#+failover-endmastertaotaoMaster2127.0.0.16381
3451:
X05Jun21:
05:
58.203#+switch-mastertaotaoMaster2127.0.0.16381127.0.0.16380
3451:
X05Jun21:
05:
58.203*+slaveslave127.0.0.1:
6379127.0.0.16379@taotaoMaster2127.0.0.16380
3451:
X05Jun21:
05:
58.203*+slaveslave127.0.0.1:
6381127.0.0.16381@taotaoMaster2127.0.0.16380
4.集群
即使有了主从复制,每个数据库都要保存整个集群中的所有数据,容易形成木桶效应。
使用Jedis实现了分片集群,是由客户端控制哪些key数据保存到哪个数据库中,如果在水平扩容时就必须手动进行数据迁移,而且需要将整个集群停止服务,这样做非常不好的。
Redis3.0版本的一大特性就是集群(Cluster),接下来我们一起学习集群。
4.1.架构
(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.
(2)节点的fail是通过集群中超过半数的节点检测失效时才生效.
(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
(4)redis-cluster把所有的物理节点映射到[0-16383]slot(插槽)上,cluster负责维护node<->slot<->value
4.2.修改配置文件
1、设置不同的端口,6379、6380、6381
2、开启集群,cluster-enabledyes
3、指定集群的配置文件,cluster-config-file"nodes-xxxx.conf"
4.3.创建集群
4.3.1.安装ruby环境
因为redis-trib.rb是有ruby语言编写的所以需要安装ruby环境。
yum-yinstallzlibrubyrubygems
geminstallredis
手动安装:
rz上传redis-3.2.1.gem
geminstall-lredis-3.2.1.gem
4.3.2.创建集群
首先,进入redis的安装包路径下:
cd/usr/local/src/redis/redis-3.0.1/src/
执行命令:
./redis-trib.rbcreate--replicas0192.168.56.102:
6379192.168.56.102:
6380192.168.56.102:
6381
--replicas0:
指定了从数据的数量为0
注意:
这里不能使用127.0.0.1,否则在Jedis客户端使用时无法连接到!
redis-trib用法:
4.3.3.测试
什么情况?
?
(error)MOVED7638127.0.0.1:
6380
因为abc的hash槽信息是在6380上,现在使用redis-cli连接的6379,无法完成set操作,需要客户端跟踪重定向。
redis-cli-c
看到由6379跳转到了6380,然后再进入6379看能否get到数据
还是被重定向到了6380,不过已经可以获取到数据了。
4.4.使用Jedis连接到集群
添加依赖,要注意jedis的版本为2.7.2
说明:
这里的jc不需要关闭,因为内部已经关闭连接了。
4.5.插槽的分配
通过clusternodes命令可以查看当前集群的信息:
该信息反映出了集群中的每个节点的id、身份、连接数、插槽数等。
当我们执行setabc123命令时,redis是如何将数据保存到集群中的呢?
执行步骤:
1、接收命令setabc123
2、通过key(abc)计算出插槽值,然后根据插槽值找到对应的节点。
(abc的插槽值为:
7638)
3、重定向到该节点执行命令
整个Redis提供了16384个插槽,也就是说集群中的每个节点分得的插槽数总和为16384。
./redis-trib.rb脚本实现了是将16384个插槽平均分配给了N个节点。
注意:
如果插槽数有部分是没有指定到节点的,那么这部分插槽所对应的key将不能使用。
4.6.插槽和key的关系
计算key的插槽值:
key的有效部分使用CRC16算法计算出哈希值,再将哈希值对16384取余,得到插槽值。
什么是有效部分?
1、如果key中包含了{符号,且在{符号后存在}符号,并且{和}之间至少有一个字符,则有效部分是指{和}之间的部分;
a)key={hello}_tatao的有效部分是hello
2、如果不满足上一条情况,整个key都是有效部分;
a)key=hello_taotao的有效部分是全部
4.7.新增集群节点
再开启一个实例的端口为6382
执行脚本:
./redis-trib.rbadd-node192.168.56.102:
6382192.168.56.102:
6379
已经添加成功!
查看集群信息:
发现没有插槽数。
接下来需要给6382这个服务分配插槽,将6379的一部分(1000个)插槽分配给6382:
查看节点情况:
4.8.删除集群节点
想要删除集群节点中的某一个节点,需要严格执行2步:
1、将这个节点上的所有插槽转移到其他节点上;
a)假设我们想要删除6380这个节点
b)执行脚本:
./redis-trib.rbreshard192.168.56.102:
6380
c)选择需要转移的插槽的数量,因为3380有5128个,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Redis 集群