Redis学习记录|常见数据类型与操作命令记录
本文为黑马redis教程笔记
作用
- 作为缓存使用
- 高频,复杂的统计数据
- 单服到集群的优化
- session,token的管理等
命名规则
表名:主键名:主键值:属性名
拥有类型
redis | java |
---|---|
string | Sting |
hash | HashMap |
list | LinkedList |
set | HashSet |
sort-set | TreeSet |
String类型操作
#添加/修改数据
set key value
mset key1 val1 key2 val2
#获取数据
get key
mget key1 key2
#删除数据
del key
# 获取数据字符个数
strlen key
#追加信息到原始信息后/不存在就新建
append key val
#设置数值数据增加指定范围的值
incr key
incrby key increment
incrbyfloat key increment
#设置数值数据减少指定范围的值
decr key
decrby key increment
# 设置数据具有指定生命周期
setex key seconds val
psetex key millseconds val
hash 类型数据的基本操作
- 添加/修改数据
hset 可以field val
hmset key field1 val1 field2 val2 ...
- 获取数据
hget key field
hmget key field1 field2
hgetall key
- 删除数据
hdel key field1 [field2]
- 获取哈希表中字段的数量
hlen key
-获取哈希表中是否存在指定字段
hexists key field
- 获取哈希表中所有字段名或字段值
hkeys key
hvals key
- 设置指定字段的数值数据增加指定范围的值
hincrby key field increment
hincrbyfloat key field increment
- 如果不存在则新建否则不做反应
hsetnx key field val
list类型
- 数据存储需求:存储多个数据,并对数据进入存储空间的顺序进行区分
- 需要的存储结构:一个存储空间保存多个数据,且通过数据可以体现进入顺序
- list类型:保存多个数据,底层使用双向链表存储结构
- 保存数据都是string类型,最多232-1个元素
- list具有索引,且操作以队列或栈出入操作
- 放入顺序,与取出顺序相反,最后进的是第一个
命令
- 添加/修改数据
lpush key val1 [val2]...
rpush key val1 [val2]...
- 获取数据
lrange key start stop
lindex key index
llen key
- 获取并移除数据
lpop key
rpop key
- 规定时间内获取并移除数据
blpop key1 [key2] timeout
brpop key1 [key2] timeout
- 移除指定数据
lrem key count value #cout数量(几个)
set类型数据的基本操作
- 添加数据
sadd key member1 [member2]
- 获取全部数据
smember key
- 删除数据
srem key member1 [member2]
- 获取集合数据总量
scard key
- 判断集合中是否包含指定数据
sismember key number
- 随机获取集合中指定数量的数据
srandmember key [count]
- 随机获取集合中的某个数据并将该数据移除集合
spop key
- 求两个集合的交集,并集,差集
sinter key1 [key2]
sunion key1 [key2]
sdiff key1 [key2]
- 求两个集合的交集、并集、差集并存储到指定集合中
sinterstore destination key1 [key2]
sunionstore destination key1 [key2]
sdiffstore destination key1 [key2]
- 将指定数据从原始集合中移动到目标集合中
smove source destination member
sorted_set类型
- 在set的存储基础上添加可排序字段(score)
- score(64位)是一个double值,可能会丢失精度
命令
- 添加数据
zadd key score1 member1 [score2 member2]
- 获取全部数据
zrange key start stop [WITHSCORES]
zreverange key start stop [WITHSCORES]
- 删除数据
zrem key member [member ...]
- 按条件获取数据
zrangebyscore key min max [WITHSCORES] [LIMIT]
zreverangebyscore key max min [WITHSCORES]
- 条件删除数据
zremrangebyrank key start stop
zremrangebyscore key min max
- 获取集合数量
zcard key
zcount key min max
- 集合交、并操作
zinterstore destination numkeys key [key ...]
zunionstore destination numkeys key [key ...]
- 获取数据对应的索引(排名)
zrank key member
zrevrank key member
- score值获取与修改
zscore key member
zincrby key increment member
通用操作
- 为指定key设置有效期
expire key seconds
pexpire key milliseconds
expireat key timestamp
pexpireat key milliseconds-timestamp
- 获取key的有效时间
ttl key
pttl key
ttl返回值
-1: key存在但未设置有效时间
-2: key不存在
其余: 剩余时间
- 切换key从时效性转换为永久性
persist key
- 查询key
keys pattern
查询规则:*匹配任意数量的任意符号 ?配合一个任意符号 []匹配一个指定符号
cmd | result |
---|---|
keys * | 查询所有 |
keys it* | 查询所有以it开头 |
keys *it | 查询所有以it结尾 |
keys ??it | 查询前两个字符任意,后以it结尾 |
keys it:? | 以it:开头,最后一个字符任意 |
keys u[st]er:1 | 以u开头,以er:1结尾,中间包含一个字母s或t |
- 为key改名
rename key newkey
renamenx key newkey
- 对所有key排序
sort
-其他key通用操作
help cmd
数据库操作
总共分为16个库,其实占用空间是一大块
- 切换数据库
select index
- 其他操作
quit #退出
ping #PONG 测试连通性
echo message
持久化
持久化是利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制成为持久化
防止数据的意外丢失,确保数据安全性
- save指令
手动执行一次保存操作,会在data目录下生成.rdb持久化文件
save
相关配置
dbfilename dump.rdb
说明:配置本地数据库文件名,默认值dump.rdb
经验:通常设置为dump-端口号.rdb
dir
说明:设置存储.rdb文件路径
经验:通常设置在data中
rdbcompression yes
说明: 设置存储至本地数据库时是否压缩数据,默认yes,采用LZF压缩
经验: 通常能默认为开启状态,设置成no,可节省cpu运行时间,但会使存储的文件变大
rdbchecksum yes
说明: 设置是否进行RDB文件格式校验,该校验过程在写文件和读文件过程均进行
经验: 通常默认为开启状态,如果设置为no,可以节约读写性过程为10%时间消耗,但有一定的数据损坏风险
- bgsave指令
手动启动后台保存操作,但不是立刻执行
bgsave
(插入一张图5, 6)
save与bgsave对比
0方式 | save指令 | bgsave指令 |
---|---|---|
读写 | 同步 | 异步 |
阻塞客户端指令 | 是 | 否 |
额外消耗内存 | 否 | 是 |
启动新进程 | 否 | 是 |
RDB的优缺点
优点
- 是一个紧凑压缩的二进制文件,存储效率较高
- 内部存储的是redis在某个时间点的数据快照,非常适用于数据备份,全量复制等场景
- 恢复数据的速度要比AOF快很多
- 应用: 服务器中每X小时执行bgsave备份,并将RBD文件拷贝到远程机器中,用于灾难恢复
缺点
- RDB方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能性丢失数据;
- bgsave指令每次运行要执行fork操作创建子进程,要牺牲掉一些性能;
- Redis的众多版本中未进行RDB文件格式版本的统一,有可能出现个版本服务之间数据格式无法兼容现象
RDB的不足
- 存储的数据量较大,效率较低:每次读写都是all data,数据量大时,效率低
- 大数据量下的IO性能较低
- 基于fork创建子进程,内存产生额外消耗
- 宕机带来的数据丢失风险
AOF概念
- AOF持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程。
- AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式。
AOF 写数据三种策略
-
always(每次)
每次写入操作均同步到AOF文件中,数据零误差,性能较低,不建议用
-
everysec(每秒)
每秒将缓冲区的指令都同步到AOF文件中,数据准确性高,性能较高,建议使用,也是默认位置在系统突然宕机的情况下丢失1秒内的数据
-
no(系统控制)
由操作系统控制每次同步到AOF文件的周期,整体过程不可控
AOF功能开启
-
配置
appendonly yes|no
-
作用
是否开启AOF持久化功能,默认不开启状态
-
配置
appendfsync always|everysec|no
-
作用
AOF写数据策略
AOF相关配置
-
配置
appendfilename filename
-
作用
AOF持久化文件名,默认文件名为appendonly.aof, 建议配置为appendonly-端口号.aof
-
配置
dir
-
作用
AOF持久化文件保存路径,与RDB持久化文件保持一致即可
AOF重写
对同一数据的若干条命令执行结果转化为最终结果数据对应的指令进行记录。(剔除重复指令,仅保存有效指令)
- 降低磁盘占用量,提高磁盘利用率
- 提高持久化效率,降低持久化写时间,提高IO性能
- 降低数据恢复耗时,提高数据恢复效率
AOF重写规则
-
进程内已超时的数据不再写入文件
-
忽略无效指令,重写时使用进程内数据直接生成,这样新的AOF文件只保留最终数据的写入命令
-
对同一数据的多条写命令合并为一条命令
为防止数据量过大造成客户端缓冲区溢出,对list、set、hash、zset等类型,每条指令最多写入64个元素
AOF重写方式
-
手动重写
# 命令 bgrewriteaof
-
自动重写
# 配置文件 auto-aof-rewrite-min-size size auto-aof-rewrite-percentage percentage
AOF自动重写方式
info
指令可查看当前redis服务器设置的全部信息
-
自动重写
auto-aof-rewrite-min-size size #具体数量 auto-aof-rewrite-percentage percent #百分比
-
自动重写触发比对参数(运行指令
info Persistence
获取具体信息)aof_current_size aof_base_size
-
自动重写触发条件
aof_current_size > auto-aof-rewrite-min-size (aof_current_size-aof_base_size)/aof_base_size >= auto-aof-rewrite-percentage
AOF重写流程
RDB与AOF对比
持久化方式 | RDB | AOF |
---|---|---|
占用存储空间 | 小(数据级:压缩) | 大(指令级:重写) |
存储速度 | 慢 | 快 |
恢复速度 | 快 | 慢 |
数据安全性 | 会丢失数据 | 依据策略决定 |
资源消耗 | 高/重量级 | 低/轻量级 |
启动优先级 | 低 | 高 |
- 综合对比
- 不能承受数分钟内的数据丢失,对业务数据非常敏感,选用AOF
- 能承受数分钟的数据丢失,且追求大数据集的恢复速度,选用RDB
- 灾难恢复选用RDB
- 双保险策略,同时开启RDB和AOF,重启后,优先使用AOF恢复数据,降低丢失数据的量
事务
事务的基本操作
-
开启事务
multi
-
作用
设定事务的开启位置,此指令执行后,后续的所有指令均加入到事务中
-
执行事务
exec
-
作用
设定事务的结束位置,同时执行事务。与multi成对出现,成对使用
-
取消事务
discard
-
作用
终止当前事务的定义,发生在multi之后,exec之前
错误情况
-
语法错误
输入命令出错,所有命令均不执行
-
运行错误
输入命令正确,但无法正确执行,运行时,正确的命令正确执行,错误命令不会执行
锁
基本操作
-
对key添加监视锁,在执行exec前如果key发生了变化,终止事务执行
watch key1 [key2....]
-
取消对所有key的监视
unwatch
-
使用setnx设置一个公共锁
setnx lock-[key] value
setnx是有值设置失败,无值则返回设置成功,操作完毕通过del操作释放锁
-
返回设置成功,拥有控制权,进行下一步的具体业务操作
-
对返回失败的,无控制权,排队或等待
-
-
使用expire为锁key添加时间限定
expire lock-key second
pexpire lock-key milliseconds
### 配置
#### 日志配置
- 日志级别 开发级别`verbose` 生产环境`notice`简化日志输出量,降低日志IO
```powershell
loglevel debug|verbose|notice|warning
-
日志记录文件名
logfile 端口号.log
客户端配置
-
设置同一时间最大客户端连接数,默认无限制,超过限制则关闭新的连接
maxclients 0
-
客户端闲置等待最大时常,达到最大值后关闭连接,如需关闭该功能,设置为0
timeout 300
多服务器快捷配置
-
导入并加载指定配置文件信息,用于快速创建redis公共配置较多的redis实例配置文件,便于维护
include /path/server-端口号.conf
数据清理
逐出策略
当redis执行每个命令前,会调用
freeMemoryIfNeeded()
检测内存是否充足,如果内存不满足新加入数据的最低存储要求,redis要临时删除一些数据为当前指令清理存储空间。逐出过程不一定100%能够清理出可用的内存空间,如果不成功则反复执行,当对所有数据尝试完毕后,不能达到清理要求,则报错。
逐出配置
-
最大可用内存
占用物理内存的比例,默认为0,表示不限制。生产环境根据需求设定,通常设置在50%以上
maxmemory
-
每次选取待删除数据的个数
选取数据时并不会全库扫面描,采用随机获取数据的方式
maxmemory-samples
-
删除策略
达到最大内存后,对被挑选出来的数据进行删除的策略
maxmemory-policy volatile-lru
-
策略
-
检测易失数据(可能会过期的数据集)
- volatile-lru:淘汰最近很少用的数据
- volatile-lfu:淘汰最近使用频率最少的数据
- volatile-ttl:淘汰将要过期的数据
- volatile-random: 任意选择数据淘汰
-
检测全库数据
- allkeys-lru:淘汰最近很少用的数据
- allkeys-lfu:淘汰最近使用频率最少的数据
- allkeys-random: 任意选择数据淘汰
-
放弃数据逐出
1.no-enviction(逐出):禁止逐出数据(v4.0中默认策略),会引发OOM错误
-
过期数据特征
-
redis是一种内存级数据库,所有数据均存在内存中,内存中的数据可以通过TTL指令获取其状态
返回值类型
- XX:具有时效的数据
- -1: 永久有效的数据
- -2: 已经过期的数据或被删除的数据或未定义的数据
-
redis内存空间
存储空间是key-value对,还有一个expires区域,里面存储的是value地址(key)和过期时间(value)
-
删除策略目标
在内存占用与CPU占用之间寻找一种平衡,如果只考虑一个,会造成redis性能下降,甚至引发服务器宕机或内存泄漏
-
删除策略
-
定时删除
- 创建定时器,当key设置有过期时间,且过期时间达到时,由定时器任务立即执行对键的删除操作
- 优势:节约内存,到点就删除,快速释放掉不必要的内存占用
- 缺点:CPU压力大,无论CPU负载量多高,均占用CPU,会影响redis服务器响应时间和指令吞吐量
- 总结: 用处理器性能换取存储空间
-
惰性删除
- 数据达到过期时间,不做处理,等下次访问该数据时如果未过期返回数据,发现已过期,删除返回不存在
- 优点: 节约CPU性能,发现必须删除的时候才删除
- 缺点: 内存压力很大,出现长期占用内存的数据
- 总结: 用存储空间换取处理器性能
-
定期删除
-
Redis启动服务器初始化时,读取配置server.hz的值,默认为10
-
每秒钟执行server.hz次
serverCron() -> databasesCron() -> activeExpireCycle()
-
activeExpireCycle()对每个expires[*]逐一进行检测,每次执行250ms/server.hz
-
对某个expires[*]检测时,随机挑选W个key检测
- 如果key超时,删除key
- 如果一轮中删除的key的数量>W*25%,循环该过程
- 如果一轮中删除的key的数量<=Wx25%,检查下一个expires[*], 0-15循环
- W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值
-
参数current_db用于记录activeExpireCycle()进入哪个expires[*]执行
-
如果activeExpireCycle()执行时间到期,下次从current_db继续向下执行
-
周期性轮询redis库中的时效性数据,采用随机抽取的策略,利用过期数据占比的方式控制频度
-
特点1:CPU性能占用设置有峰值,检测频度可自定义设置
-
特点2:内存压力不是很大,长期占用内存的冷数据会被持续清理
-
总结:周期性抽查存储空间(随机抽查,重点抽查)
定时删除 节约内存,无占用 不分时段占用CPU资源,频度高 拿时间换空间 惰性删除 内存占用严重 延时执行,CPU利用率高 拿空间换时间 定期删除 内存定期随机清理 每秒花费固定的CPU资源维护内存 随机抽查,重点抽查
-
-
高级数据类型
Bitmaps类型的基础操作
-
获取指定key对应偏移量上的bit值
getbit key offset
-
设置指定key对应偏移量上的bit值,value只能是1或0
setbit key offset value
-
对指定key按位进行交、并、非、异或操作、并将结果保存到destKey中
bitop op destKey key1 [key2...]
- and:交
- or:并
- not: 非
- xor:异或
-
统计指定key中1的数量
bitcount key [start end]
HyperLogLog类型的基本操作
-
添加数据
pfadd key element [element...]
-
统计数据
pfcount key [key...]
-
合并数据
pfmerge destKey sourceKey [sourcekey...]
-
相关说明
- 用于进行基数统计,不是集合,不保存数据,只记录数量而不是具体数据
- 核心是基数估算算发,最终数值存在一定误差
- 误差范围:基数估计的结果是一个带有0.81%标准错误的近似值
- 耗费空间极小,每个hyperloglog key占用了12K的内存用于标记基数
- pfadd命令不是一次性分配12K内存使用,会随基数的增加内存逐渐增大
- pfmerge命令合并后占用的存储空间为12K,无论合并之前数据量多少
GEO坐标类型的基本操作
所有操作均需在同一个key中操作, 经、纬度、member可理解为地区,只能计算水平,不能计算垂直
-
添加坐标点
geoadd key longitude latitude member [longitude latitude member]
-
获取坐标点
geopos key member [member ...]
-
计算坐标点距离
geodist key member1 member2 [unit: m km mi(英里) ft(英尺)]
-
根据坐标求范围内数据
georadius key longitude latitude radius m|km|mi(英里)|ft(英尺) [withcoord:将经纬度一并返回] [withdist:将位置与中心点距离返回] [withhash] [count count: 数量]
-
根据点求范围内数据
geoadiusbymember key member radius m|km|mi(英里)|ft(英尺) [withcoord:将经纬度一并返回] [withdist:将位置与中心点距离返回] [withhash] [count count: 数量]
-
获取指定点对应的坐标
geohash key member [member ...]
主从复制简介
主从复制
就是将master中的数据即时,有效的复制到slave中
特征:一个master可以拥有多个slave,一个slave只对应一个master
职责:
- master:
- 写数据
- 执行写操作,将出现变化的数据自动同步到slave
- 读数据(可忽略)
- slave
- 读数据
- 写数据(禁止)
作用:
- 读写分离:master写,slave读 提高服务器的读写负载能力
- 负载均衡:基于主从结构,配合读写分离,由slave分担master负载,并根据需求的变化,改变slave的数量,通过多个节点分担数据读取负载,大大提高Redis服务器并发量与数据吞吐量
- 故障恢复:当master出现问题时,由slave提供服务,实现快速的故障恢复
- 数据冗余:实现数据热备份,是持久化之外的一种数据冗余方式
- 高可用基石:基于主从复制,构建哨兵模式与集群,实现Redis的高可用方案
数据连接阶段
- 设置master的地址和端口,保存master的信息
- 建立socket连接
- 发送ping
- 身份验证
- 发送slave端口信息
-
状态
slave:
保存master的地址端口
master:
保存slave的端口
总体:
之间创建了连接的socket
主从连接(s->m)
-
方式一: 客户端发送命令
slaveof <masterip><masterport>
-
方式二:启动服务器参数
redis-server --slaveof <masterip><masterport>
-
方式三:服务器配置
slaveof <masterip><masterport>
主从断开连接
-
客户端发送命令
slaveof no one
授权访问
-
master配置文件设置密码
requirepass <pwd>
-
master客户端发送命令设置密码
config set requirepass <pwd> config get requirepass
-
slave客户端发送命令设置密码
auth <pwd>
-
slave配置文件设置密码
masterauth <pwd>
-
启动客户端设置密码
redis-cli -a <pwd>
数据同步阶段工作流程
请求同步数据
创建RDB同步数据
恢复RDB同步数据
请求部分同步数据
恢复部分同步数据
- 其中复制细节
状态:
slave:
具有master端的全部数据,包含RDB过程接收的数据
master:
保存slave当前数据同步的位置
总体:
之间完成了数据的克隆
数据同步阶段master状态
-
如果master数据量巨大,数据同步阶段应该避免流量高峰期,避免造成master阻塞,影响业务正常执行
-
复制缓冲区大小设定不合理,会导致数据溢出。如果进行全量复制周期太长,进行部分复制时发现数据已经存在丢失的情况,必须进行第二次全量复制,致使slave陷入死循环状态
repl-backlog-size 1mb
-
master单机内存占用主机内存的比例不应过大,留30%-50%的内存用于执行bgsave命令和创建复制缓冲区
数据同步阶段slave状态
-
为避免slave进行同步时,服务器响应阻塞或数据不同步,建议同步期间关闭对外服务
slave-server-stable-data yes|no
-
数据同步阶段,master发送给slave信息可以理解为master时slave的一个客户端,主动向slave发送命令
-
避免多个slave同时对master请求数据同步
-
slave过多时建于调整拓扑结构,由一主多从变为树状结构,中间的节点既是master也是slave,由于树结构过深,导致slave与顶层master间数据同步延迟较大,数据一致性较差,谨慎选择
命令传播阶段的部分复制
-
命令传播阶段出现了断网现象
- 网络闪断闪联——忽略
- 短时间网络中断——部分复制
- 长时间网络中断——全量复制
-
部分复制的三个核心要素
-
服务器运行id(run id)
概念:每台服务武器运行时的身份识别码,一台服务器多次运行可生成多个
组成: 由40位字符组成,是一个随机的16进制字符
作用:保证擦奥做均在同一台服务器,识别对方
实现方式:每台服务器启动自动生成,master首次连接slave时,会将自己的id发送给slave,slave保存id,通过info Server命令可以查看节点的runid
-
主服务器的复制积压缓冲区
-
主从服务器的复制偏移量
-
复制缓冲区
又名复制积压缓冲区,是一个先进先出(FIFO)的队列,用于存储服务器执行过的命令,每次传播命令,master都会将传播的命令记录下来,并存储在复制缓冲区
- 复制缓冲区默认数据存储空间大小是1M,由于存储空间大小是固定的,当入队元素的数量大于队列长度时,最先入队的元素会被弹出,而新元素会被放入队列
-
组成
偏移量和字节值
-
工作原理
-
通过offset区分不同的slave当前数据传播的差异
-
master记录已发送的信息对应的offset
-
slave记录已接收的信息对应的offset
内部是一个数组,记录的是AOF文件的内容
偏移量 0001 0002 0003 0004 0005 0006 0007 0008 字节量 … $3 \r \n s e t \r
-
-
由来:每台服务器启动时,如果开启有AOF或被连接成为master节点,则会创建复制缓冲区
-
作用:用于保存master收到的所有指令(仅限影响数据更变的指令例如set)
-
数据来源:当master接收到主客户端的指令时,除了执行指令,还会将指令存到缓冲区中
主从服务器复制偏移量(offset)
- 概念:一个数字,描述复制缓冲区中的指令字节位置
- 分类:
- master复制偏移量:记录发送给所有slave的指令字节对应的位置(多个)
- slave复制偏移量:记录slave接收master发送过来的指令字节对应的位置(一个)
- 数据来源:
- master端:发送一次记录一次
- slave端:接受一次记录一次
- 作用:同步信息,比对master与slave的差异,当slave断线后,恢复数据使用
命令传播阶段流程
心跳机制
-
进入命令传播阶段,master与slave间需要进行信息交换,使用心跳机制进行维护,实现双方连线保持在线
-
master心跳:
- 指令:ping
- 周期:由repl-ping-slave-period决定,默认10s
- 作用:判断slave是否在线
- 查询:info replication 获取slave最后一次连接时间间隔,lag项维持在0或1视为正常
-
slave心跳任务:
- 指令: replconf ack{offset}
- 周期:1s
- 作用:汇报slave自己的复制偏移量,获取最新的数据变更指令,判断master是否在线
-
当slave多数掉线,或延迟过高时,master为保障数据稳定性,将拒绝所有信息同步操作
min-slaves-to-write 2 min-slaves-max-lag 10
slave数量少于2个,或者所有slave的延迟都>=10s时,强制关闭master写功能,停止数据同步
-
slave数量由slave发送replconf ack命令做确认
-
slave延迟由slave发送replconf ack命令做确认
哨兵
是一个分布式系统,用于对主从结构中的每台服务器进行监控,当出现故障时通过投票机制选择新的master并将所有的slave连接到新的master
配置哨兵
-
配置一拖二的主从结构
-
配置三个哨兵(3,5,7…奇数个,配置相同,端口不同)
参看
sentinel.conf
-
启动哨兵
redis-sentinel sentinel-端口号.conf
哨兵的作用
-
监控
不断的检查master与slave是否正常运行
master存活检测、master与slave运行情况检测
-
通知(提醒)
当被监控的服务器出现问题时,向其他哨兵、客户端发送通知
-
自动故障转移
断开master与slave连接,选取一个slave作为master,将其他slave连接到新的master,并告知客户端新的服务器地址
-
注意
哨兵也是一台服务器,只是不提供数据服务
通常哨兵设置为>=3的单数