redis的发布与订阅,主从架构,哨兵架构,cluster集群
下载编译安装redis
wget http://download.redis.io/releases/redis-4.0 .10 .tar.gz
tar -zxvf redis-4.0 .10 .tar.gz
cd redis-4.0 .10
执行: make && make install
/usr/local/bin /redis-server
/usr/local/bin /redis-cli
redis的发布和订阅
将信息 message 发送到指定的频道 channel
订阅频道,可以同时订阅多个频道
取消订阅指定的频道, 如果不指定频道,则会取消订阅所有频道
订阅一个或多个符合给定模式的频道,每个模式以 * 作为匹配符,比如 it* 匹配所 有以 it 开头的频道( it.news 、 it.blog 、 it.tweets 等等), news.* 匹配所有 以 news. 开头的频道( news.it 、 news.global .today 等等),诸如此类
退订指定的规则, 如果没有参数则会退订所有规则
查看订阅与发布系统状态
注意:使用发布订阅模式实现的消息队列,当有客户端订阅channel后只能收到后续发布到该频道的消息,之前发送的不会缓存,必须Provider和Consumer同时在线。
127.0 .0 .1 :6379 > PSUBSCRIBE music
127.0 .0 .1 :6379 > PUBLISH music singsong
redis的持久化 rdb 和 aof
# 前言:
Redis是一种内存型数据库,一旦服务器进程退出,数据库的数据就会丢失,为了解决这个问题,Redis提供了两种持久化的方案,将内存中的数据保存到磁盘中,避免数据的丢失。
RBD模式
#### RDB 模式
RDB(持久化)
内存数据保存到磁盘
在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)
优点:速度快,适合做备份,主从复制就是基于RDB持久化功能实现
rdb通过再redis中使用save命令触发 rdb
rdb配置参数:
dir /data/6379/
dbfilename dbmp.rdb
每过900秒 有1个操作就进行持久化
save 900秒 1个修改类的操作
save 300秒 10个操作
save 60秒 10000个操作
save 900 1
save 300 10
save 60 10000
daemonize yes
port 6379
logfile /data/6379 /redis.log
dir /data/6379
dbfilename dbmp.rdb
bind 10.0 .0 .10 127.0 .0 .1
requirepass redhat
save 900 1
save 300 10
save 60 10000
AOF模式
记录服务器执行的所有变更操作命令(例如set del 等),并在服务器启动时,通过重新执行这些命令来还原数据集
优点:最大程序保证数据不丢
缺点:日志记录非常大
appendonly yes
appendfsync always 总是修改类的操作
everysec 每秒做一次持久化
no 依赖于系统自带的缓存大小机制
daemonize yes
port 6379
logfile /data/6379 /redis.log
dir /data/6379
dbfilename dbmp.rdb
requirepass redhat
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec
redis 持久化方式有哪些?有什么区别?
rdb:基于' 快照的持久化 ' ,速度更快,一般用作备份,主从复制也是依赖于rdb持久化功能
aof:' 以追加的方式记录 ' redis操作日志的文件。可以最大程度的保证redis数据安全,类似于mysql的binlog
主从同步
原理:
1. 从服务器向主服务器发送 SYNC 命令。
2. 接到 SYNC 命令的主服务器会调用BGSAVE 命令,创建一个 RDB 文件,并使用缓冲区记录接下来执行的所有写命令。
3. 当主服务器执行完 BGSAVE 命令时,它会向从服务器发送 RDB 文件,而从服务器则会接收并载入这个文件。
4. 主服务器将缓冲区储存的所有写命令发送给从服务器执行。
主从总结:
1 、在开启主从复制的时候,使用的是RDB方式的,同步主从数据的
2 、同步开始之后,通过主库命令传播的方式,主动的复制方式实现
3 、2.8 以后实现PSYNC的机制,实现断线重连
vim /data/6379 /redis.conf
port 6379
daemonize yes
pidfile /data/6379 /redis.pid
loglevel notice
logfile "/data/6379/redis.log"
dbfilename dump.rdb
dir /data/6379
protected-mode no
vim /data/6380 /redis.conf
port 6380
daemonize yes
pidfile /data/6380 /redis.pid
loglevel notice
logfile "/data/6380/redis.log"
dbfilename dump.rdb
dir /data/6380
protected-mode no
mkdir -p /data/{6380 ,6379 ,6381 }/
redis-server 6381. conf
redis-server 6380. conf
redis-server 6379. conf
info
info replication
SLAVEOF 127.0 .0 .1 6380
slaveof no one
哨兵集群
https://www.cnblogs.com/pyyu/p/9718679. html
Redis-Sentinel主从复制高可用
1. Redis-Sentinel是redis官方推荐的高可用性解决方案,
2. 当用redis作master-slave的高可用时,如果master本身宕机,redis本身或者客户端都没有实现主从切换的功能。
3. 而redis-sentinel就是一个独立运行的进程,用于监控多个master-slave集群,
4. 自动发现master宕机,进行自动切换slave > master。
1. 不时的监控redis是否良好运行,如果节点不可达就会对节点进行下线标识
2. 如果被标识的是主节点,sentinel就会和其他的sentinel节点“协商”,如果其他节点也人为主节点不可达,就会选举一个sentinel节点来完成自动故障转义
3. 在master-slave进行切换后,master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变,即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换
每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个 PING 命令
如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel 标记为主观下线。
如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
当有足够数量的 Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态, 则Master会被标记为客观下线
在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master,Slave发送 INFO 命令
当Master被 Sentinel 标记为客观下线时,Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
若没有足够数量的 Sentinel 同意 Master 已经下线, Master 的客观下线状态就会被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复, Master 的主观下线状态就会被移除。
主观下线和客观下线
主观下线:Subjectively Down,简称 SDOWN,指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线:Objectively Down, 简称 ODOWN,指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断,并且通过 SENTINEL is -master-down-by-addr 命令互相交流之后,得出的Master Server下线判断,然后开启failover.
SDOWN适合于Master和Slave,只要一个 Sentinel 发现Master进入了ODOWN, 这个 Sentinel 就可能会被其他 Sentinel 推选出, 并对下线的主服务器执行自动故障迁移操作。
ODOWN只适用于Master,对于Slave的 Redis 实例,Sentinel 在将它们判断为下线前不需要进行协商, 所以Slave的 Sentinel 永远不会达到ODOWN。
redis主从复制背景问题
Redis主从复制可将主节点数据同步给从节点,从节点此时有两个作用:
1. 一旦主节点宕机,从节点作为主节点的备份可以随时顶上来。
2. 扩展主节点的读能力,分担主节点读压力。
但是问题是:
3. 一旦主节点宕机,从节点上位,那么需要人为修改所有应用方的主节点地址(改为新的master地址),还需要命令所有从节点复制新的主节点
redis-sentinel就可以解决了
主从复制架构
配置如下:
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/var/redis/data/"
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/var/redis/data/"
slaveof 127.0 .0 .1 6379
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
dir "/var/redis/data/"
slaveof 127.0 .0 .1 6379
port 26379
dir /var/redis/data/
logfile "26379.log"
// 当前Sentinel节点监控 192.168 .119 .10 :6379 这个主节点
// 2 代表判断主节点失败至少需要2 个Sentinel节点节点同意
// mymaster是主节点的别名
sentinel monitor s23sbredis 127.0 .0 .1 6379 2
//每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达,如果超过30000 毫秒30s且没有回复,则判定不可达
sentinel down-after-milliseconds s23sbredis 30000
//当Sentinel节点集合对主节点故障判定达成一致时,Sentinel领导者节点会做故障转移操作,选出新的主节点,
原来的从节点会向新的主节点发起复制操作,限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs s23sbredis 1
//故障转移超时时间为180000 毫秒
sentinel failover-timeout s23sbredis 180000
daemonize yes
port 26380
dir /var/redis/data/
logfile "26380.log"
sentinel monitor s23sbredis 127.0 .0 .1 6379 2
sentinel down-after-milliseconds s23sbredis 30000
sentinel parallel-syncs s23sbredis 1
sentinel failover-timeout s23sbredis 180000
daemonize yes
port 26381
dir /var/redis/data/
logfile "26381.log"
sentinel monitor s23sbredis 127.0 .0 .1 6379 2
sentinel down-after-milliseconds s23sbredis 30000
sentinel parallel-syncs s23sbredis 1
sentinel failover-timeout s23sbredis 180000
daemonize yes
sed "s/26379/26380/g" 26379redis-sentinel.conf >26380redis-sentinel.conf
mkdir -p /var/redis/data/
redis-server 6379redis.conf
redis-server 6380redis.conf
redis-server 6381redis.conf
redis-sentinel 26379redis-sentinel.conf
redis-sentinel 26380redis-sentinel.conf
redis-sentinel 26381redis-sentinel.conf
redis-cluster集群
port 7000
daemonize yes
dir "/opt/redis/data"
logfile "7000.log"
dbfilename "dump-7000.rdb"
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-require-full-coverage no
redis-7001.conf
redis-7002.conf
redis-7003.conf
redis-7004.conf
redis-7005.conf
redis-server 7000redis.conf
redis-server 7001redis.conf
redis-server 7002redis.conf
redis-server 7003redis.conf
redis-server 7004redis.conf
redis-server 7005redis.conf
yum install ruby -y
wget http://rubygems.org/downloads/redis-3.3 .0 .gem
gem install -l redis-3.3 .0 .gem
find / -name redis-trib.rb
redis-trib.rb create --replicas 1 127.0 .0 .1 :7000 127.0 .0 .1 :7001 127.0 .0 .1 :7002 127.0 .0 .1 :7003 127.0 .0 .1 :7004 127.0 .0 .1 :7005
redis-cli -p 7000 cluster info
redis-cli -p 7000 cluster nodes
集群主节点状态
redis-cli -p 7000 cluster nodes | grep master
集群从节点状态
redis-cli -p 7000 cluster nodes | grep slave
redis-cli -c -p 7000
https://www.cnblogs.com/pyyu/p/9844093. html
1. 利用 python 操作redis 哨兵
2. 利用 redis替换 Django的session
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步