实验目的
掌握redis的原理、特性,关系型数据库和非关系型数据库的对比,数据类型命令操作,Redis的消息队列两种方式,redis的主从复制,包括级联复制、无盘模式和有盘模式的操作,哨兵机制实现监听主从复制。
实验主要内容
1、redis数据结构类型命令操作
2、redis实现消息队列两种方式
3、redis实现手动主从复制(级联复制、无盘模式和有盘模式)
4、Redis实现哨兵机制监听主从复制
实验环境与准备
3台拍完快照配置好的rocky9的linux主机,ip为主节点10.100,从节地为10.110和10.120
四、实验分析与设计思路
建议基于画图、思维导图等模式,结合文字描述,写的清晰、明了、得体

主从复制的数据分为全量数据同步和增量数据同步
从服务器连接主服务器,发送PSYNC命令,主服务器接收到PSYNC命令后,开始执行BGSAVE命令生成RDB快照文件并使用缓冲区记录此后执行的所有写命令主服务器BGSAVE执行完后,向所有从服务器发送RDB快照文件,并在发送期间继续记录被执行的写命令从服务器收到快照文件后丢弃所有旧数据,载入收到的快照至内存主服务器快照发送完毕后,开始向从服务器发送缓冲区中的写命令从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令后期同步会先发送自己slave_repl_offset位置,只同步新增加的数据,不再全量同步

1多个sentinel发现并确认master有问题
2.选举出一个sentinel作为领导。
3.选出一个slave作为master。
4.通知其余slave成为新的master的slave。
5.通知客户端主从变化
6.等待老的master复活成为新master的slave。
redis 的哨兵机制(Sentinel)
主从架构无法实现master和slave角色的自动切换,即当master出现redis服务异常、主机断电、磁盘损坏等问题导致master无法使用,而redis主以复制无法实现自动的故障转移(将slave 自动提升为新master),需要手动修改环境配置才能切换到slave redis服务器,另外当单台Redis服务器性能无法满足业务写入需求的时候,也无法横向扩展Redis服务的并行写入性能
哨兵机制增加新机器最好是两个两个增加
五、详细实验过程
特别注意!!!!!! 以下操作仅是在测试环境操作,keys *操作在工作环境中切勿使用!!!
1、redis数据结构类型命令操作

①字符串
set key value get key del key操作
127.0.0.1:6379> set name zz
127.0.0.1:6379> get name
127.0.0.1:6379> del name zz

setnx操作
127.0.0.1:6379> setnx age 25
127.0.0.1:6379> setnx age 25

INCR命令操作
127.0.0.1:6379> INCR ii
127.0.0.1:6379> get ii

mget mset命令
127.0.0.1:6379> mset id 1 name za name ji
127.0.0.1:6379> mget id name

set 设置Key可以定义ex有效期 TTL查看过期时间,-1为永久有效,-2为此值不存在
127.0.0.1:6379> ttl name
127.0.0.1:6379> SET name zy ex 15
127.0.0.1:6379> ttl name

②列表操作基于索引(下标)指引
LPUSH 创建或推送列表
127.0.0.1:6379> LPUSH name 'ikun' 'ji' 'jini' 'taimei'
![]()
LINDEX 基于下标显示元素数据
127.0.0.1:6379> LINDEX name 0
127.0.0.1:6379> LINDEX name 2
127.0.0.1:6379> LINDEX name 3

LRANGE 遍历列表连续下标的所有元素
127.0.0.1:6379> LRANGE name 0 5

LLEN 查询列表的数据长度
127.0.0.1:6379> LLEN name
![]()
LPOP 左侧开始弹出N个元素
127.0.0.1:6379> LPOP name 1
127.0.0.1:6379> LPOP name 2
127.0.0.1:6379> LPOP name 3
127.0.0.1:6379> LPOP name 1

③:集合特点
元素内部没有次序,不重复。此数据类型一般用于取并集交集等相关的操作。
SADD 创建集合
127.0.0.1:6379> SADD set1 'ji'
127.0.0.1:6379> SADD set2 'ni'
127.0.0.1:6379> SADD set3 'tai' 'mei'

SMEMBERS 列出某个集合的相关元素
127.0.0.1:6379> SMEMBERS set2
127.0.0.1:6379> SMEMBERS set1
127.0.0.1:6379> SMEMBERS set3

SINTER:取多个集合的交集
127.0.0.1:6379> SINTER set1 set2 set3
![]()
SUNION:取并集
127.0.0.1:6379> sunion set1 set2 set3

SDIFF:取差集
127.0.0.1:6379> SDIFF set1 set2 set3
![]()
④:有序集合
特点:有序、无重复元素、每个元素是由score和value组成、score可以重复、value不可重复
ZADD 添加有序集合 ZRANGE:正序排序
127.0.0.1:6379> zadd zset 1 'ji'
127.0.0.1:6379> zadd zset 2 'ni'
127.0.0.1:6379> zadd zset 3 'tai'
127.0.0.1:6379> zadd zset 4 'mei'
127.0.0.1:6379> ZRANGE zset 0 -1

⑤:哈希hash
哈希:即字典,hash的value即也为一个键值对(kv)
HSET添加HASH数据 HDEL删除hash中的某个键值对 HGET 查询hash中的某个键值对数据
127.0.0.1:6379> HSET 9527 name 'ikun' class 'zhenaifen'
127.0.0.1:6379> HGETALL 9527

2、redis实现消息队列两种方式
①生产者/消费者模式
生产者消费者模式下,多个消费者同时监听一个队列,但是一个消息只能被最先抢到消息的消费者消费,即消息任务是一次性读取和处理
127.0.0.1:6379> LPUSH channel ji 推进创建数据
127.0.0.1:6379> LPUSH channel ni
127.0.0.1:6379> LPUSH channel tai
127.0.0.1:6379> LPUSH channel mei
127.0.0.1:6379> LPUSH channel 0 -1
127.0.0.1:6379> LRANGE channel 0 -1 遍历所有数据

127.0.0.1:6379> RPOP channel 重复取出数据,直到数据取空为止

②:发布者/订阅者模式
在发布者/订阅者模式模式下,发布者将消息发布到指定的channel里面,凡是监听该channel的消费者都会收到一份消息,这种模式类似于是收音机的广播模式,即凡是收听到某个频道的听众都会收到主持人发布的相同的消息内容,此模式常用于语音聊天、群通知、群公告等场景。
发布者发布消息,会发送给每一个订阅者
127.0.0.1:6379> PUBLISH FM94.6 'ikun jihe'

订阅者订阅状态是会收到发布者的信息的
127.0.0.1:6379> SUBSCRIBE FM94.6

3、redis实现手动主从复制(级联复制、无盘模式和有盘模式)
①手动进行主从复制
将10.110和10.120连接到100主节点
查看主节点的replication 信息,connected_slaves的数量还是0,就是还没有连接的从节点
127.0.0.1:6379> info replication

127.0.0.1:6379> REPLICAOF 192.168.10.100 6379
127.0.0.1:6379> INFO replication
下面为110的操作:查看从节点110的连接信息

127.0.0.1:6379> CONFIG SET masterauth 666666 设置与主节点同步的认证密码(要与主接地一致)

127.0.0.1:6379> INFO replication 查看与主节点连接状态,up是处于连接状态

同理120也是和110一样的操作。
现在100已经有了两个从节点
127.0.0.1:6379> info replication

验证主从复制是否成功,对比主从节点的数据
127.0.0.1:6379> keys *
127.0.0.1:6379> dbsize
下图是主节点的数据

此图为从节点120的数据,110数据也是这样

主从复制的效果就实现了。
②级联复制
断开110与主节点100的连接,然后将110连接到120上实现级联复制效果
127.0.0.1:6379> REPLICAOF 192.168.10.120 6379
127.0.0.1:6379> CONFIG SET masterauth 666666
127.0.0.1:6379> info replication

从节点120查看信息
127.0.0.1:6379> INFO replication

repl-diskless-sync no # 是否使用无盘同步RDB文件,现在默认为yes,no为不使用无盘,需要将RDB文件保存到磁盘后发送给slave, yes为支持无盘,支持无盘就是RDB文件不需要保存至本地磁盘,而且直接通过socket文件发送给slave
③无盘模式
主节点为100,从节点为110和120,非级联复制模式
[root@node-1 ~]# vim /usr/local/redis/etc/redis.conf



主节点将AOF持久化功能模式关闭,删除掉data下的所有文件
[root@node-1 ~]# cd /usr/local/redis/data/
[root@node-1 data]# rm -rf *
[root@node-1 data]# ll

从节点110和120也同样删除掉data下所有的文件
[root@node-2 ~]# cd /usr/local/redis/data/
[root@node-2 data]# rm -rf *
[root@node-2 data]# ll


此时主节点和从节点中的数据均为空的,运行脚本在主节点停服的时候将数据导入到主节点中
[root@node-1 data]# vim /root/redis_test.py
[root@node-1 ~]# python redis_test.py 下面是脚本内容

cd /usr/local/redis/data
ll 主节点的data下没有dump.rdp文件说明无盘模式的主从复制验证成功

查看主节点的数据量
[root@node-1 ~]# redis-cli -a 666666
127.0.0.1:6379> dbsize

查看从节点10.110和10.120
![]()



无盘模式主从复制成功
④有盘模式
[root@node-1 ~]# vim /usr/local/redis/etc/redis.conf 主节点修改配置文件

清空redis中的所有数据
127.0.0.1:6379> FLUSHALL

[root@node-1 ~]# systemctl restart redis.service 重启主节点redis服务,将无盘模式改为有盘模式
[root@node-1 ~]# python redis_test.py 运行写入数据的python脚本
可以看到主节点中已经写入完成了数据

[root@node-1 ~]# ll /usr/local/redis/data/ 查看运行之后主节点和从节点的data下是否产生了rdp文件,都生成了,证明有盘模式验证成功



4、哨兵机制监听主从复制
[root@node-1 ~]# vim /usr/local/redis/etc/redis.conf
bind 0.0.0.0 -::1 在脚本中已经配好了

[root@node-2 ~]# vim /usr/local/redis/etc/redis.conf 从节点110配置redis.conf配置文件


将修改好的redis.conf 主配置文件传给从节点120
scp /usr/local/redis/etc/redis.conf 192.168.10.120:/usr/local/redis/etc/

编辑哨兵sentinel的配置文件
cp /root/redis-7.2.4/sentinel.conf /usr/local/redis/etc/
chown -R redis:redis sentinel.conf 为sentinel.conf 更改属主属组
编辑sentinel主配置文件
vim /usr/local/redis/etc/sentinel.conf






[root@node-1 etc]# egrep -vE "^#|^$" /usr/local/redis/etc/sentinel.conf

将配置好的sentinel.conf 哨兵配置文件传送给从节点
[root@node-1 etc]# scp sentinel.conf 192.168.10.110:/usr/local/redis/etc/
[root@node-1 etc]# scp sentinel.conf 192.168.10.120:/usr/local/redis/etc/

传送过去从节点还需要再给sentinel.conf文件更改属主属组,两个从节点都需要
[root@node-2 etc]# chown -R redis:redis sentinel.conf

主从节点均关闭redis服务systemctl stop redis.service
![]()
主从节点均启动sentinel服务
/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf --supervised systemd

主从节点均开启redis服务
[root@node-1 etc]# systemctl start redis
![]()
127.0.0.1:6379> INFO replication 可以看到现在100主节点上有两个从节点

关闭主节点redis服务
127.0.0.1:6379> SHUTDOWN

查看sentinel日志
tail -f /usr/local/redis/log/sentinel.log

查看新主节点110的信息,可以看到已经成为了master



哨兵模式验证成功!
总结
主从架构无法实现master和slave角色的自动切换,即当master出现redis服务异常、主机断电、磁盘损坏等问题导致master无法使用,而redis主以复制无法实现自动的故障转移(将slave 自动提升为新master),需要手动修改环境配置 才能切换到slave redis服务器,另外当单台Redis服务器性能无法满足业务写入需求的时候,也无法横向扩展Redis服务的并行写入性能 哨兵机制增加新机器最好是两个两个增加
需要解决以上的两个核心问题:
master和slave角色的无缝切换,让业务无感知从而不影响业务便用。
可横向动态扩展Redis服务器,从而实现多台服务器并行写入以实现更高并发的目的。
Redis 集群实现方式:
客户端分片: 由应用决定将不同的KEY发送到不同的Redis服务器.
代理分片: 由代理决定将不同的KEY发送到不同的Redis服务器,代理程序如:codis,twemproxy等
Redis Cluster
1341

被折叠的 条评论
为什么被折叠?



