【Redis学习笔记二】三种特殊数据类型、事务的基本操作、锁、持久化、发布订阅、主从复制、哨兵模式

news2024/11/16 23:38:38

文章目录

  • 三种特殊数据类型
    • geospatial 地理位置
    • Hyperloglog 基数统计
    • Bitmaps
  • 事务
    • 基本操作
    • 悲观锁
    • 乐观锁
  • 持久化
    • RDB（Redis Database）
    • AOF（Append Only File）
    • 拓展
  • Redis发布订阅
    • 命令
    • 原理
    • 缺点
    • 应用
  • redis主从复制
    • 概念
    • 作用
    • 为什么使用集群
    • 环境配置
    • 一主二从配置
    • 使用规则
    • 复制原理
  • 哨兵模式
    • 概述
    • 测试
    • 哨兵模式优缺点
    • 哨兵模式的全部配置

三种特殊数据类型

geospatial 地理位置

Geo 底层的索引结构是 sorted set

在redis 3.2版本推出；这个功能可以推算地理位置的信息，两地之间的距离

只有6个命令

  • 有效的经度介于 -180 度至 180 度之间。
  • 有效的纬度介于 -85.05112878 度至 85.05112878 度之间。

当用户尝试输入一个超出范围的经度或者纬度时，GEOADD命令将返回一个错误。

说明: 没有 GEODEL 命令，因为可以使用 ZREM来删除元素。Geo 底层的索引结构是 sorted set 。

#添加地理位置
#规则：两级无法直接添加，一般下载城市数据，通过程序一次性导入
#纬度 经度 名称
127.0.0.1:6379> GEOADD China:city 114.13 22.54 Shenzhen
(integer) 1

GEOPOS用于从给定的 key 里返回所有指定名称(member)的位置（经度和纬度），不存在的返回 nil;

命令接受可变数量的位置元素作为输入， 所以即使用户只给定了一个位置元素， 命令也会返回数组回复

127.0.0.1:6379> GEOPOS China:city Beijing Chongqing
1) 1) "116.39999896287918091"
   2) "39.90000009167092543"
2) 1) "106.49999767541885376"
   2) "29.52999957900659211"

GEODIST 命令用于返回两个给定位置之间的直线距离。

如果两个位置之间的其中一个不存在， 那么命令返回空值。

距离单位参数说明：

  • m ：米，默认单位。
  • km ：千米。
  • mi ：英里。
  • ft ：英尺。
127.0.0.1:6379> GEODIST China:city Beijing Shanghai km
"1068.3949"

GEODIST命令以给定的经纬度为中心， 返回键包含的位置元素当中， 与中心的距离不超过给定最大距离的所有位置元素

命令会返回额外的信息：

WITHDIST ： 在返回位置元素的同时， 将位置元素与中心之间的距离也一并返回。 距离的单位和用户给定的范围单位保持一致。

WITHCOORD ： 将位置元素的经度和维度也一并返回

WITHHASH ： 以 52 位有符号整数的形式， 返回位置元素经过原始 geohash 编码的有序集合分值。 这个选项主要用于底层应用或者调试， 实际中的作用并不大。

命令默认返回未排序的位置元素。 通过以下两个参数， 用户可以指定被返回位置元素的排序方式：

ASC ： 根据中心的位置， 按照从近到远的方式返回位置元素。 DESC ： 根据中心的位置， 按照从远到近的方式返回位置元素。

在默认情况下，命令会返回所有匹配的位置元素。 虽然用户可以使用 COUNT <count> 选项去获取前 N 个匹配元素， 但是因为命令在内部可能会需要对所有被匹配的元素进行处理， 所以在对一个非常大的区域进行搜索时， 即使只使用 COUNT 选项去获取少量元素， 命令的执行速度也可能会非常慢。 但是从另一方面来说， 使用 COUNT 选项去减少需要返回的元素数量， 对于减少带宽来说仍然是非常有用的

127.0.0.1:6379> GEORADIUS China:city 110 30 500 km withdist
1) 1) "Chongqing"
   2) "341.9374"
2) 1) "Xian"
   2) "483.8340"

用于返回一个或多个位置元素的 Geohash 表示。Redis GEO 使用 geohash 来保存地理位置的坐标。

一个数组， 数组的每个项都是一个 geohash 。 命令返回的 geohash 的位置与用户给定的位置元素的位置一一对应。

127.0.0.1:6379> GEOHASH China:city  Shanghai Hangzhou
1) "wtw3s57v8j0"
2) "wtmkq069cc0"

Hyperloglog 基数统计

基数：不重复元素

redis 2.8.9版本更新了该数据结构

优点：占用的内存是固定的，2^64不同的元素的技术，只需要12kb的内存，从内存角度看，该数据结构为首选

因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

其底层使用string数据类型

应用场景

网页的访问量（UV），用户访问多次，只能算作一个人

传统实现，存储用户的id，然后每次进行比较。当用户变多之后这种方式及其浪费空间，而我们的目的只是计数，Hyperloglog就能帮助我们利用最小的空间完成。

----------PFADD--PFCOUNT---------------------
127.0.0.1:6379> PFADD myelemx a b c d e f g h i j k # 添加元素
(integer) 1
127.0.0.1:6379> type myelemx # hyperloglog底层使用String
string
127.0.0.1:6379> PFCOUNT myelemx # 估算myelemx的基数
(integer) 11
127.0.0.1:6379> PFADD myelemy i j k z m c b v p q s
(integer) 1
127.0.0.1:6379> PFCOUNT myelemy
(integer) 11

----------------PFMERGE-----------------------
127.0.0.1:6379> PFMERGE myelemz myelemx myelemy # 合并myelemx和myelemy 成为myelemz
OK
127.0.0.1:6379> PFCOUNT myelemz # 估算基数
(integer) 17

如果允许容错，那么一定可以使用Hyperloglog !

如果不允许容错，就使用set或者自己的数据类型即可 ！

Bitmaps

使用位存储；是一串连续的二进制数字，每一位所在的位置为偏移；非常的省内存

应用场景：只有是和否的统计，类似于打卡

------------setbit--getbit--------------
127.0.0.1:6379> setbit sign 0 1 # 设置sign的第0位为 1 
(integer) 0
127.0.0.1:6379> setbit sign 2 1 # 设置sign的第2位为 1  不设置默认是0
(integer) 0
127.0.0.1:6379> setbit sign 3 1
(integer) 0
127.0.0.1:6379> setbit sign 5 1
(integer) 0
127.0.0.1:6379> type sign
string

127.0.0.1:6379> getbit sign 2 # 获取第2位的数值
(integer) 1
127.0.0.1:6379> getbit sign 3
(integer) 1
127.0.0.1:6379> getbit sign 4 # 未设置默认是0
(integer) 0

-----------bitcount----------------------------
127.0.0.1:6379> BITCOUNT sign # 统计sign中为1的位数
(integer) 4

事务

基本操作

本质：一组命令的集合，一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行

一次性，顺序性，排他性！执行一些列的命令

redis事务没有隔离级别的概念

所有命令在事务中并未直接执行，只有发起执行命令的时候才会执行

redis单条命令是保存原子性的，但是事务不保证原子性

redis的事务

开启事务

127.0.0.1:6379> multi
OK

命令入队

127.0.0.1:6379> SET k1 v1
QUEUED
127.0.0.1:6379> SET k2 v2
QUEUED
127.0.0.1:6379> GET k2
QUEUED
127.0.0.1:6379> SET k3 v3
QUEUED

执行事务，执行完之后，事务就不再开启了，需要则需重新开启

127.0.0.1:6379> exec
1) OK
2) OK
3) "v2"
4) OK

放弃事务，事务队列中的命令都不会被执行

127.0.0.1:6379> DISCARD

编译时异常：代码有问题、命令有错。事务中所有的命令都不会被执行

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> error k1 # 这是一条语法错误命令
(error) ERR unknown command `error`, with args beginning with: `k1`, # 会报错但是不影响后续命令入队 
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors. # 执行报错
127.0.0.1:6379> get k1 
(nil) # 其他命令并没有被执行

运行时异常：事务队列中存在语法性错误，那么其他命令可以正常执行错误命令抛出异常

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> INCR k1 # 这条命令逻辑错误（对字符串进行增量）
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range # 运行时报错
4) "v2" # 其他命令正常执行

# 虽然中间有一条命令报错了，但是后面的指令依旧正常执行成功了。
# 所以说Redis单条指令保证原子性，但是Redis事务不能保证原子性。

悲观锁

很悲观，什么时候都会出问题，无论做什么都会加锁，很影响性能

乐观锁

认为什么都不会出问题，所以不会上锁，更新数据的时候判断一下，在此期间是否有人修改过这个数据

获取version

更新的时候比较version

redis监视测试

127.0.0.1:6379> set money 100 # 设置余额:100
OK
127.0.0.1:6379> set use 0 # 支出使用:0
OK
127.0.0.1:6379> watch money # 监视money (上锁)
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY use 20
QUEUED
127.0.0.1:6379> exec # 监视值没有被中途修改，事务正常执行
1) (integer) 80
2) (integer) 20

测试多线程修改值，使用watch可以当作redis的乐观锁操作

我们启动另外一个客户端模拟插队线程。

线程1：

127.0.0.1:6379> watch money # money上锁
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY use 20
QUEUED
127.0.0.1:6379> 	# 此时事务并没有执行

模拟线程插队，线程2：

127.0.0.1:6379> INCRBY money 500 # 修改了线程一中监视的money
(integer) 600

回到线程1，执行事务：

127.0.0.1:6379> EXEC # 执行之前，另一个线程修改了我们的值，这个时候就会导致事务执行失败
(nil) # 没有结果，说明事务执行失败
127.0.0.1:6379> get money # 线程2 修改生效
"600"
127.0.0.1:6379> get use # 线程1事务执行失败，数值没有被修改
"0"

解锁获取最新值，然后再加锁进行事务。

解锁获取最新值，然后再加锁进行事务。

如果发现事务执行失败，先unwatch进行解锁。

注意：每次提交执行exec后都会自动释放锁，不管是否成功

持久化

redis是内存数据库，如果不讲内存中的数据库保存到磁盘，一旦服务器进程结束，数据库状态也会消失

RDB（Redis Database）

image-20231006154454272

会在指定的时间内将内存中的数据集快照写入磁盘，恢复时将snapshot文件直接读入内存中

redis会单独fork一个子进程来进行持久化，会先将数据都写入一个一个临时文件，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行任何IO操作，进而确保了较高性能；

如果需要进行大规模数据的恢复且对于数据恢复的完整性不是很敏感，那么RDB更高效；

缺点：最后一次持久化的数据可能丢失

默认的是RDB模式，一般情况下不需要修改

在生产环境下，有时候会对其进行备份

RDB保存的文件：dump.rdb

触发情况（如果没有文件，会自动生成）

  1. 满足save规则
  2. 执行flushall命令
  3. 退出redis

使用save命令，会立刻对当前内存中的数据进行持久化，但是会阻塞，save是同步命令，会占用redis的主进程，若redis数据非常多，则命令执行会很慢

image-20231006164141027

bgsave是异步进行，进行持久化操作时候还可以继续响应客户端请求

image-20231006164250361

两者对比

image-20231006164303429

恢复rdb：将rdb文件放在redis的启动目录下，redis在启动时会自动检查并恢复其中的数据

查看需要存在的位置

config get dir

优点：

  1. 适合大规模的数据恢复
  2. 如果对数据完整性要求不高

缺点：

  1. 需要一定的时间间隔，如果redis意外宕机，最后一次修改的数据就没了
  2. fork进程的时候，会占用一定的内存空间

AOF（Append Only File）

将我们所有的命令都记录下来，类似history，恢复的时候，将所有操作再执行

image-20231006160501373

以日志的形式记录每个写操作，将redis执行过的命令记录下来（读操作除外），只许追加文件而不可以改写文件。redis启动之初会读取该文件重新构建数据。换言之redis重启时会根据日志内容将写指令从前到后的执行一次

文件：appendonly.aof

默认是不开启，需要手动进行配置，之后重启redis就可以生效

如果aof文件有错误，则无法启动redis，需要修复文件

redis提供工具

redis-check-aof --fix

配置

appendonly yes  # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分的情况下，rdb完全够用
appendfilename "appendonly.aof"

# appendfsync always # 每次修改都会sync 消耗性能
appendfsync everysec # 每秒执行一次 sync 可能会丢失这一秒的数据
# appendfsync no # 不执行 sync ,这时候操作系统自己同步数据，速度最快

优点

  1. 每一次修改都同步，提高文件完整性
  2. 每秒同步一次，可能会丢失一秒的数据
  3. 从不同步，效率最高

缺点

  1. 数据文件AOF远远大于RDB，修复速度比rdb慢
  2. AOF运行效率也要比RDB慢，所以redis默认的配置是RDB

重写规则

aof默认是文件的无限追加，所以文件会很大

image-20231006163227580

拓展

  1. RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储
  2. AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
  3. 只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
  4. 同时开启两种持久化方式
    • 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
    • RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。
  5. 性能建议
    • 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。
    • 如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
    • 如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。

Redis发布订阅

发布订阅是一种消息通信模式，发送者发送消息，订阅者接收消息

redis客户端可订阅任意数量的频道

订阅/发布消息图：

image-20231006170311103

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

image-20231006170323827

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

image-20231006170343762

命令

PSUBSCRIBE pattern [pattern..] #订阅一个或多个符合给定模式的频道。
PUNSUBSCRIBE pattern [pattern..] #退订一个或多个符合给定模式的频道。
PUBSUB subcommand [argument[argument]] #查看订阅与发布系统状态。
PUBLISH channel message #向指定频道发布消息
SUBSCRIBE channel [channel..] #订阅给定的一个或多个频道。
UNSUBSCRIBE channel [channel..] #退订一个或多个频道

示例

#------------订阅端----------------------
127.0.0.1:6379> SUBSCRIBE sakura # 订阅sakura频道
Reading messages... (press Ctrl-C to quit) # 等待接收消息
1) "subscribe" # 订阅成功的消息
2) "sakura"
3) (integer) 1
1) "message" # 接收到来自sakura频道的消息 "hello world"
2) "sakura"
3) "hello world"
1) "message" # 接收到来自sakura频道的消息 "hello i am sakura"
2) "sakura"
3) "hello i am sakura"


#--------------消息发布端-------------------

127.0.0.1:6379> PUBLISH sakura "hello world" # 发布消息到sakura频道

(integer) 1

127.0.0.1:6379> PUBLISH sakura "hello i am sakura" # 发布消息

(integer) 1




#-----------------查看活跃的频道------------

127.0.0.1:6379> PUBSUB channels



"sakura"

原理

Redis是使用C实现的，通过分析 Redis 源码里的 pubsub.c 文件，了解发布和订阅机制的底层实现，籍此加深对 Redis 的理解。

Redis 通过 PUBLISH 、SUBSCRIBE 和 PSUBSCRIBE 等命令实现发布和订阅功能。

每个 Redis 服务器进程都维持着一个表示服务器状态的 redis.h/redisServer 结构， 结构的 pubsub_channels 属性是一个字典， 这个字典就用于保存订阅频道的信息，其中，字典的键为正在被订阅的频道， 而字典的值则是一个链表， 链表中保存了所有订阅这个频道的客户端。发送消息则相当于遍历列表发送。

也可以设定对某一个key值发布消息，消息发布后所有被订阅的客户端都会收到消息，用法：实时聊天系统

image-20231006172320748

客户端订阅，就被链接到对应频道的链表的尾部，退订则就是将客户端节点从链表中移除

缺点

  1. 如果一个客户端订阅了频道，但自己读取消息的速度却不够快的话，那么不断积压的消息会使redis输出缓冲区的体积变得越来越大，这可能使得redis本身的速度变慢，甚至直接崩溃。
  2. 这和数据传输可靠性有关，如果在订阅方断线，那么他将会丢失所有在短线期间发布者发布的消息。

应用

  1. 消息订阅：公众号订阅，微博关注等等（起始更多是使用消息队列来进行实现）
  2. 多人在线聊天室。

稍微复杂的场景，我们就会使用消息中间件MQ处理。

redis主从复制

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（Master/Leader）,后者称为从节点（Slave/Follower）， 数据的复制是单向的！只能由主节点复制到从节点（主节点以写为主、从节点以读为主）。

默认情况下，每台Redis服务器都是主节点，一个主节点可以有0个或者多个从节点，但每个从节点只能由一个主节点。

作用

  1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余的方式。
  2. 故障恢复：当主节点故障时，从节点可以暂时替代主节点提供服务，是一种服务冗余的方式
  3. 负载均衡：在主从复制的基础上，配合读写分离，由主节点进行写操作，从节点进行读操作，分担服务器的负载；尤其是在多读少写的场景下，通过多个从节点分担负载，提高并发量。
  4. 高可用基石：主从复制还是哨兵和集群能够实施的基础。

为什么使用集群

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的（宕机），原因如下：

1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；

2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"多读少写"。

对于这种场景，我们可以使如下这种架构：

image-20231006174410953

主从复制，读写分离！ 80% 的情况下都是在进行读操作！减缓服务器的压力！架构中经常使用！ 一主二从！

只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis！

总结

  1. 单台服务器难以负载大量的请求
  2. 单台服务器故障率高，系统崩坏概率大
  3. 单台服务器内存容量有限。

环境配置

只配置从库，不用配置主库！

127.0.0.1:6379> info replication
# Replication
role:master # 角色
connected_slaves:0 # 从机数量
master_replid:3b54deef5b7b7b7f7dd8acefa23be48879b4fcff
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

复制3个配置文件，然后修改对应的信息

  1. 端口
  2. pid名字
  3. log文件名
  4. dump.rdb名字

启动单机多服务集群，可通过进程信息查看：

ps -ef|grep redis

一主二从配置

默认情况下，每台Redis服务器都是主节点；

一般情况下只用配置从机就好了

认老大！一主（79）二从（80，81）

使用此命令就可以为从机配置主机：

SLAVEOF 127.0.0.1 [PORT]

真实的从主配置应该在配置文件中配置，这样的话是永久的，我们这里使用的是命令，暂时的！

使用规则

1.从机只能读，不能写，主机可读可写但是多用于写。

127.0.0.1:6381> set name sakura # 从机6381写入失败
(error) READONLY You can't write against a read only replica.


127.0.0.1:6380> set name sakura # 从机6380写入失败

(error) READONLY You can't write against a read only replica.


127.0.0.1:6379> set name sakura

OK

127.0.0.1:6379> get name

"sakura"

2.当主机断电宕机后，默认情况下从机的角色不会发生变化 ，集群中只是失去了写操作，当主机恢复以后，又会连接上从机恢复原状。

3.当从机断电宕机后，若不是使用配置文件配置的从机，再次启动后作为主机是无法获取之前主机的数据的，若此时重新配置称为从机，又可以获取到主机的所有数据。这里就要提到一个同步原理。

4.第二条中提到，默认情况下，主机故障后，不会出现新的主机，有两种方式可以产生新的主机：

  • 从机手动执行命令slaveof no one,这样执行以后从机会独立出来成为一个主机
  • 使用哨兵模式（自动选举）

如果没有老大了，这个时候能不能选择出来一个老大呢？手动！

如果主机断开了连接，我们可以使用SLAVEOF no one让自己变成主机！其他的节点就可以手动连接到最新的主节点（手动）！如果这个时候老大修复了，那么就重新连接！

复制原理

Slave 启动成功连接到 master 后会发送一个sync同步命令

Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。

全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：Master 继续将新的所有收集到的修改命令依次传给slave，完成同步

但是只要是重新连接master，一次完全同步（全量复制）将被自动执行！ 我们的数据一定可以在从机中看到！

层层链路

上一个M连接下一个S

image-20231006204910955

这时候也可以完成主从复制

哨兵模式

（自动选举老大的模式）

概述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵） 架构来解决这个问题。能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

image-20231006205628313

哨兵的作用：

  • 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
  • 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

image-20231006205639112

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

测试

配置哨兵配置文件 sentinel.conf

# sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1

后面的这个数字1，代表主机挂了，slave投票看让谁接替成为主机，票数最多的，就会成为主机！

哨兵模式优缺点

优点：

  1. 哨兵集群，基于主从复制模式，所有主从复制的优点，它都有
  2. 主从可以切换，故障可以转移，系统的可用性更好
  3. 哨兵模式是主从模式的升级，手动到自动，更加健壮 缺点：
  4. Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦
  5. 实现哨兵模式的配置其实是很麻烦的，里面有很多配置项

哨兵模式的全部配置

完整的哨兵模式配置文件 sentinel.conf

# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379
# 哨兵sentinel的工作目录
dir /tmp
# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
#通知脚本
# shell编程
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由运维来配

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1066948.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

JVM222

JVM222

文章目录 JVM222运行时数据区的内部结构线程程序计数器&#xff08;PC寄存器&#xff09;虚拟机栈 JVM222 运行时数据区的内部结构 概述 本节主要讲的是运行时数据区&#xff0c;也就是下图这部分&#xff0c;它是在类加载器加载完成后的阶段&#xff0c;如下图&#xff1a; …
阅读更多...
MySql学习笔记：MySql性能优化

MySql学习笔记：MySql性能优化

本文是自己的学习笔记&#xff0c;主要参考以下资料 - 大话设计模式&#xff0c;程杰著&#xff0c;清华大学出版社出版 - 马士兵教育 1、MySql调优金字塔2、MySql调优2.1、查询性能2.1.1、慢查询2.1.1.1、总结 1、MySql调优金字塔 Mysql 调优时设计三个层面&#xff0c;分别是…
阅读更多...
华为云云耀云服务器L实例评测｜云耀云服务器L实例部署JumpServer开源堡垒机

华为云云耀云服务器L实例评测｜云耀云服务器L实例部署JumpServer开源堡垒机

华为云云耀云服务器L实例评测&#xff5c;云耀云服务器L实例部署JumpServer开源堡垒机 一、前言二、JumpServer 介绍2.1 JumpServer 简介2.2 JumpServer特点2.3 JumpServer支持的资产类型 三、本次实践介绍3.1 本次实践简介3.2 本次环境规划3.3 操作系统及配置要求3.4 数据库环…
阅读更多...
雷达波束高度估计、折射分类、大气波导现象概念

雷达波束高度估计、折射分类、大气波导现象概念

一、雷达波束高度估计 雷达波束在地球大气层中的传播并非直线，而是受到大气层的影响呈现出一种弯曲的形态，这种现象称为大气折射。这是由于地球大气的密度并非均匀，从地面到高空，大气的密度逐渐减小，因此电磁波在穿过大气层时，会因大气密度的变化而改变传播方向，形成弯曲…
阅读更多...
二蛋赠书四期：《Go编程进阶实战：开发命令行应用、HTTP应用和gRPC应用》

二蛋赠书四期：《Go编程进阶实战：开发命令行应用、HTTP应用和gRPC应用》

前言 大家好&#xff01;我是二蛋&#xff0c;一个热爱技术、乐于分享的工程师。在过去的几年里&#xff0c;我一直通过各种渠道与大家分享技术知识和经验。我深知&#xff0c;每一位技术人员都对自己的技能提升和职业发展有着热切的期待。因此&#xff0c;我非常感激大家一直…
阅读更多...
光伏发电预测（GRU模型，Python代码）

光伏发电预测（GRU模型，Python代码）

运行效果&#xff1a;光伏发电预测&#xff08;GRU模型&#xff0c;Python代码&#xff09;_哔哩哔哩_bilibili 所有库的版本&#xff1a; 1.数据集&#xff08;连续10年不间断采集三个光伏电站的发电量及天气情况&#xff0c;每隔半个小时采集一次信息&#xff0c;因此&…
阅读更多...
RT-Thread 内存管理（学习一）

RT-Thread 内存管理（学习一）

内存管理 在计算系统中&#xff0c;通常存储空间可以分为两种&#xff1a;内部存储空间和外部存储空间。 内部存储空间通常访问速度比较快&#xff0c;能够按照变量地址随机访问&#xff0c;也就是我们通常所说的RAM&#xff08;随机存储器&#xff09;&#xff0c;可以把它理…
阅读更多...
设备上架与调试步骤项目篇

设备上架与调试步骤项目篇

1.设备又哪些常见的调试方法&#xff1f; 2.设备开箱 -> 使用的步骤是什么&#xff1f; 3.开局新设备都要设置哪些功能&#xff1f; -- 工程师&#xff1a;架构设计 项目实施 故障排查 -- 调试设备&#xff1a; -- 1.WEB界面 - 界面调试 - 内容比较少的 主要项目 …
阅读更多...
一文从0到1手把手教学UI自动化测试之数据驱动！

一文从0到1手把手教学UI自动化测试之数据驱动！

在UI的自动化测试中&#xff0c;我们需要把测试使用到的数据分离到文件中&#xff0c;如果单纯的写在我们的测试模块里面&#xff0c;不是一个好的设计&#xff0c;所以不管是什么类型的自动化测试&#xff0c;都是需要把数据分离出来的。当然分离到具体的文件里面&#xff0c;…
阅读更多...
基于YOLOv5的工地安全帽、口罩检测系统

基于YOLOv5的工地安全帽、口罩检测系统

目录 1&#xff0c;YOLOv5模型原理介绍 1.1 输入侧 1.1.1 数据增强 1.1.2 自适应锚框计算 1.1.3 自适应图片缩放 1.2 Backbone 1.3 Neck 1.4 输出端 2 &#xff0c; 基于YOLOv5的工地安全帽、口罩检测系统实现流程 2.1 整体项目 2.2 代码展示 2.3 效果展示 1&a…
阅读更多...
VulnHub Mercury

VulnHub Mercury

//nmap命令大全 -sT TCP (全)连接扫描&#xff0c;准确但留下大量日志记录-sS TCP SYN (半)扫描&#xff0c;速度较快&#xff0c;不会留下日志-sP扫描存活主机-pn 不检测主机存活,不进行ping-po 扫描之前不进行ping-O 查看目标主机系统版本-sV 探测服务版本-A 全面扫描 一、修…
阅读更多...
C++day01（QT简介、C++）

C++day01（QT简介、C++）

今日任务&#xff1a; 代码&#xff1a; #include <iostream>using namespace std;int main() {/** 输入字符串统计大写、小写、数字、空格以及其他字符的个数**/string s;cout << "请输入一个字符串" << endl;//cin >> s;getline(cin,s);i…
阅读更多...
【数据分析】时间序列

【数据分析】时间序列

UTC时间&#xff1a;时间戳是以格林威治时间1970年01月01日00时00分00秒为基准计算所经过时间的秒数&#xff0c;是一个浮点数。Python的内置模块time和datetime都可以对时间格式数据进行转换&#xff0c;如时间戳和时间字符串的相互转换。 报错记录&#xff1a;AR has been re…
阅读更多...
【C++设计模式之组合模式:结构型】分析及示例

【C++设计模式之组合模式:结构型】分析及示例

简介 组合模式是一种结构型设计模式&#xff0c;它能够将对象组合成树形结构以表示“整体-部分”的层次结构&#xff0c;并且能够使用相同的方式处理单个对象和组合对象。组合模式使得客户端可以一致地处理单个对象和组合对象&#xff0c;无需关心具体的对象类型。 组合模式将对…
阅读更多...
一、Excel VBA 是个啥？

一、Excel VBA 是个啥？

Excel VBA 从入门到出门一、Excel VBA 是个啥&#xff1f;二、Excel VBA 简单使用 &#x1f44b;Excel VBA 是个啥&#xff1f; ⚽️1. Excel 中的 VBA 是什么&#xff1f;⚽️2. 为什么 VBA 很重要&#xff1f;⚽️3. 是否有无代码方法可以在 Excel 中实现工作流程自动化&…
阅读更多...
QT基础入门——界面布局和常用控件（四）

QT基础入门——界面布局和常用控件（四）

前言&#xff1a; 所谓 GUI 界面&#xff0c;归根结底&#xff0c;就是一堆组件的叠加。我们创建一个窗口&#xff0c;把按钮放上面&#xff0c;把图标放上面&#xff0c;这样就成了一个界面。在放置时&#xff0c;组件的位置尤其重要。我们必须要指定组件放在哪里&#xff0c…
阅读更多...
2023-IDEA插件推荐

2023-IDEA插件推荐

CamelCase 链接 https://plugins.jetbrains.com/plugin/7160-camelcase https://github.com/netnexus/camelcaseplugin 介绍 提供下划线、驼峰等代码风格的切换。快捷键是⇧ ⌥ U / Shift Alt U GsonFormatPlus 链接 https://plugins.jetbrains.com/plugin/14949-gs…
阅读更多...
比较好用的在线项目管理系统推荐

比较好用的在线项目管理系统推荐

好的项目管理系统首先要能满足你在管理项目中的要求&#xff0c;不同的团队规模、不同的项目对项目管理的要求都是不一样的。其次&#xff0c;引入项目管理系统的本身是为了提高管理和协作的效率&#xff0c;因此工具应该是要简单易用的&#xff0c;很多企业引入工具之后形同虚…
阅读更多...
十、pygame小游戏开发

十、pygame小游戏开发

目录 一、安装pygame二、pygame快速入门2.1 坐标系认识2.2 创建游戏主窗口2.3 实现图像绘制2.4 游戏循环和游戏时钟2.5 简单动画实现的实现2.6 监听事件2.7 精灵和精灵组三、游戏框架搭建3.1 实现飞机大战主游戏类3.2 完成游戏初始化部分3.3 使用常量代替固定的数值3.4 完成游戏…
阅读更多...
VulnHub BREAKOUT

VulnHub BREAKOUT

一、信息收集 1.端口扫描 nmap -sS -A 192.168.103.178.24发现开发了80、10000、20000 以及有smb协议 2.查看80端口 右击查看源代码&#xff0c;发现尾部有个密文加密 一看就是 Brainfuck/Ook! 加密&#xff0c;解得&#xff1a;.2uqPEfj3D<Pa-3 3.查看10000端口 是个登…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023