redis哨兵


阅读数: 次   

redis哨兵机制

redis 发布订阅

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。

Redis 客户端可以订阅任意数量的频道。

下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：

当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：

以下实例演示了发布订阅是如何工作的，需要开启两个 redis-cli 客户端。

在我们实例中我们创建了订阅频道名为 runoobChat:
第一个redis-cli客户端

1
2
3
4
5
redis 127.0.0.1:6379> SUBSCRIBE runoobChat  
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1

现在，我们先重新开启个 redis 客户端，然后在同一个频道 runoobChat 发布两次消息，订阅者就能接收到消息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
redis 127.0.0.1:6379> PUBLISH runoobChat "Redis PUBLISH test"

(integer) 1

redis 127.0.0.1:6379> PUBLISH runoobChat "Learn redis by runoob.com"

(integer) 1

# 订阅者的客户端会显示如下消息
 1) "message"
2) "runoobChat"
3) "Redis PUBLISH test"
 1) "message"
2) "runoobChat"
3) "Learn redis by runoob.com"

Redis 发布订阅命令

下表列出了 redis 发布订阅常用命令：

redis持久化rdb与aof

Redis是一种内存型数据库，一旦服务器进程退出，数据库的数据就会丢失，为了解决这个问题，Redis提供了两种持久化的方案，将内存中的数据保存到磁盘中，避免数据的丢失。

RDB持久化

redis提供了RDB持久化的功能，这个功能可以将redis在内存中的的状态保存到硬盘中，它可以手动执行。

也可以再redis.conf中配置，定期执行。

RDB持久化产生的RDB文件是一个经过压缩的二进制文件，这个文件被保存在硬盘中，redis可以通过这个文件还原数据库当时的状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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

redis持久化之RDB实践

1.启动redis服务端,准备配置文件

1
2
3
4
5
6
7
8
9
10
daemonize yes
port 6379
logfile /data/6379/redis.log
dir /data/6379              #定义持久化文件存储位置
dbfilename  dbmp.rdb        #rdb持久化文件
bind 10.0.0.10  127.0.0.1    #redis绑定地址
requirepass redhat            #redis登录密码
save 900 1                    #rdb机制 每900秒 有1个修改记录
save 300 10                    #每300秒        10个修改记录
save 60  10000                #每60秒内        10000修改记录

2.启动redis服务端

3.登录redis设置一个key

1
redis-cli -a redhat

4.此时检查目录，/data/6379底下没有dbmp.rdb文件

5.通过save触发持久化，将数据写入RDB文件

1
2
3
4
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> save
OK

redis持久化之AOF

AOF（append-only log file）
记录服务器执行的所有变更操作命令（例如set del等），并在服务器启动时，通过重新执行这些命令来还原数据集
AOF 文件中的命令全部以redis协议的格式保存，新命令追加到文件末尾。
优点：最大程序保证数据不丢
缺点：日志记录非常大

1
redis-client   写入数据  >  redis-server   同步命令   >  AOF文件

配置参数

1
2
3
4
5
AOF持久化配置，两条参数
appendonly yes
appendfsync  always    总是修改类的操作
             everysec   每秒做一次持久化
             no     依赖于系统自带的缓存大小机制

1.准备aof配置文件 redis.conf

1
2
3
4
5
6
7
8
9
10
11
12
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

2.启动redis服务

1
redis-server /etc/redis.conf

3.检查redis数据目录/data/6379/是否产生了aof文件

1
2
[root@web02 6379]# ls
appendonly.aof  dbmp.rdb  redis.log

4.登录redis-cli，写入数据，实时检查aof文件信息

1
[root@web02 6379]# tail -f appendonly.aof

5.设置新key，检查aof信息，然后关闭redis，检查数据是否持久化

1
2
3
redis-cli -a redhat shutdown
redis-server /etc/redis.conf
redis-cli -a redhat

redis 持久化方式有哪些？有什么区别？

rdb：基于快照的持久化，速度更快，一般用作备份，主从复制也是依赖于rdb持久化功能

aof：以追加的方式记录redis操作日志的文件。可以最大程度的保证redis数据安全，类似于mysql的binlog

redis哨兵

redis-Sentinel

1
2
3
4
Redis-Sentinel是redis官方推荐的高可用性解决方案，
当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。
而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，
自动发现master宕机，进行自动切换slave > master。

sentinel主要功能如下：

  • 不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识
  • 如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也人为主节点不可达，就会选举一个sentinel节点来完成自动故障转义
  • 在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

    Redis-sentinel工作机制

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    每个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 sentinel架构图

安装配置redis哨兵

服务器环境，一台即可完成操作

主节点master的redis-6379.conf

1
2
3
4
5
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/var/redis/data/"

从节点slave的redis-6380.conf

1
2
3
4
5
6
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/var/redis/data/" 
slaveof 127.0.0.1 6379      // 从属主节点

从节点slave的redis-6381.conf

1
2
3
4
5
6
port 6381
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/var/redis/data/" 
slaveof 127.0.0.1 6379      // 从属主节点

启动redis主节点

1
redis-server /etc/redis-6379.conf

测试redis主节点是否通信

1
redis-cli  ping

启动两slave节点

1
2
3
4
5
6
-rw-r--r-- 1 root root 145 Nov  7 17:44 /etc/redis-6379.conf      #这个为主，port是6379
-rw-r--r-- 1 root root  93 Nov  7 17:42 /etc/redis-6380.conf　　　 # 这个是从，port6380，并且得加上新的参数slaveof
-rw-r--r-- 1 root root 115 Nov  7 17:42 /etc/redis-6381.conf      # 这个是从，port6381，并且得加上新的参数slaveof

redis-server /etc/redis-6380.conf
redis-server /etc/redis-6381.conf

验证从节点的redis服务

1
2
3
4
[root@master  ~]$redis-cli   -p 6380 ping
PONG
[root@master  ~]$redis-cli   -p 6381 ping
PONG

检测主从关系

1
2
3
4
5
6
7
8
9
10
11
[root@master ~]# redis-cli  -p 6379 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.119.10,port=6380,state=online,offset=407,lag=0
slave1:ip=192.168.119.10,port=6381,state=online,offset=407,lag=0
master_repl_offset:407
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:406

在从节点上查看主从关系（6380、6379）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@slave 192.168.119.11 ~]$redis-cli  -p 6380 info replication
# Replication
role:slave
master_host:192.168.119.10
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:505
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

配置redis sentinel环境

1
2
3
4
5
6
7
[root@master tmp]# ll /etc/redis-*
-rw-r--r-- 1 root root 145 Nov  7 17:44 /etc/redis-6379.conf
-rw-r--r-- 1 root root  93 Nov  7 17:42 /etc/redis-6380.conf
-rw-r--r-- 1 root root 115 Nov  7 17:42 /etc/redis-6381.conf
-rw-r--r-- 1 root root 556 Nov  7 17:42 /etc/redis-sentinel-26379.conf
-rw-r--r-- 1 root root 556 Nov  7 17:42 /etc/redis-sentinel-26380.conf
-rw-r--r-- 1 root root 556 Nov  7 17:42 /etc/redis-sentinel-26381.conf

redis-sentinel-26379.conf配置文件写入如下信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// Sentinel节点的端口
port 26379  
dir /var/redis/data/
logfile "26379.log"
// 当前Sentinel节点监控 192.168.119.10:6379 这个主节点
// 2代表判断主节点失败至少需要2个Sentinel节点节点同意
// mymaster是主节点的别名
sentinel monitor mymaster 192.168.119.10 6379 2
//每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒30s且没有回复，则判定不可达
sentinel down-after-milliseconds mymaster 30000
//当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，
原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs mymaster 1
//故障转移超时时间为180000毫秒
sentinel failover-timeout mymaster 180000
1
2
redis-sentinel-26380.conf
redis-sentinel-26381.conf的配置仅仅差异是port(端口)的不同。

然后启动三个sentinel哨兵

1
2
3
redis-sentinel /etc/redis-sentinel-26379.conf
redis-sentinel /etc/redis-sentinel-26380.conf
redis-sentinel /etc/redis-sentinel-26381.conf

此时查看哨兵是否成功通信

1
2
3
4
5
6
7
8
9
[root@master ~]# redis-cli -p 26379  info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.119.10:6379,slaves=2,sentinels=3
#看到最后一条信息正确即成功了哨兵，哨兵主节点名字叫做mymaster，状态ok，监控地址是192.168.119.10:6379，有两个从节点，3个哨兵
赏

老板大气

支付宝
微信

扫一扫，分享到微信

微信分享二维码

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

很惭愧<br><br>只做了一点微小的工作<br>谢谢大家