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

已于 2023-10-14 00:03:26 修改
阅读量170 收藏 1
点赞数 1
分类专栏： 中间件 文章标签： redis 学习 笔记 后端 中间件 数据库
于 2023-10-07 20:10:06 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_73976305/article/details/133654061
版权

文章目录

三种特殊数据类型

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 # 一般都是由运维来配
RenX000
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Redis学习笔记9：主从复制
Vincent9847的博客
06-24 363
一、主从复制是什么？ 主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（master/leader),后者称为从节点（slave/follower);数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。 主从复制的作用主要包括：1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余...
Redis学习笔记之事务，持久化，主从复制（总体第三篇）
热爱编写程序的药学在读书
04-10 1073
前面两篇文章中已经学习到了redis的数据类型，及SpringBoot项目整合redis，还有一些新的数据类型的相关内容，接下来学习我们的事务等一系列内容。学习资源地址 一、事务 1、redis事务介绍 （1）概念 （2）命令 刚刚登录的时候发现报错了【执行以下命令就好啦】 （3）命令练习 执行multi就开启了组队了 当你执行了exec就你的组队的执行完成了 当你如下情况不想执行了【你中途不想再组了】 那执行如下命令即可【放弃组队】 （4）当有命令错误的情况 在组队时候错误【一
Redis入门总结（二）：主从复制，事务和发布订阅
冷血之心的博客
05-21 624
（尊重劳动成果，转载请注明出处：https://yangwenqiang.blog.csdn.net/article/details/90414751冷血之心的博客） 关注微信公众号（文强的技术小屋），学习更多技术知识，一起遨游知识海洋~ 快速导航： Redis入门总结（一）：redis配置文件，五种数据结构，线程模型和持久化方式 Redis入门总结（二）：主从复制，事务和发布订阅...
Redis学习笔记_04：Redis持久化+Redis发布订阅+Redis主从复制
耿鬼不会笑的博客
01-28 283
Redis学习笔记_04 本文基于B站UP主【遇见狂神说】视频教程 【Redis最新超详细版教程通俗易懂】进行整理/记录，仅用于个人学习交流使用 狂神主页：https://space.bilibili.com/95256449 视频地址：https://www.bilibili.com/video/BV1S54y1R7SB Redis官方中文文档：http://www.redis.cn/ 参考博客：https://blog.csdn.net/DDDDeng_/article/details/1081.
Redis学习笔记(二)高级特性之持久化、事务、主从复制及集群模式
Lizhj的博客
03-06 286
持久化 概念 利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。 意义 防止数据的意外丢失，确保数据安全性 持久化过程保存什么 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程 RDB RDB启动方式—save 命令 save 执行完之后，会在data文件夹中生成rdb文件， RDB配置相关命令 在配置文件中改写。 dbf
Redis学习笔记(三) [事务和锁机制、持久化机制、模拟主从复制、集群搭建]
从零开始的异世界JAVA学习
04-04 271
Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存、分布式、可选持久性的键值对(Key-Value)存储数据库，并提供多种语言的 API。Redis 通常被称为数据结构服务器，因为值（value）可以是字符串(String)、哈希(Hash)、列表(list)、集合(sets)和有序集合(sorted........
Redis高可用概述—持久化，主从复制，哨兵模式，集群模式_redis 的主从复制、哨兵模式
2301_76379269的博客
05-06 551
在web服务器中，高可用是指服务器可以正常访问的时间，衡量的标准是在多长时间内可以提供正常服务（99.9%、99.99%、99.999% 等等）。但是在Redis语境中，高可用的含义似乎要宽泛一些，除了保证提供正常服务(如主从分离、快速容灾技术)，还需要考虑数据容量的扩展、数据安全不会丢失等。在Redis中，实现高可用的技术主要包括持久化、复制、哨兵和集群，下面分别说明它们的作用，以及解决了什么样的问题。1.持久化：持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要作用是数据备份。
Redis学习笔记（下）：持久化RDB、AOF+主从复制（薪火相传，反客为主，一主多从，哨兵模式）+Redis集群
RuanFun的博客
10-03 1024
用ps -ef | grep redis查找进程，用kill -9 进程号杀死进程，然后重新redis-server /etc/redis.conf启动，再在xshell中开启一个新的会话，cd /usr/local/bin，ll查看，会看到appendonlydir文件夹，此时redis-cli进入redis中查看发现并没有数据，说明RDB和AOF同时开启时默认读取AOF。主从复制：主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。
Redis基础：基本介绍、redis的应用场景、五种数据类型、持久化操作、主从模式
chenlong的博客
06-04 238
一、Redis基本概念介绍和特性1.1 Redis基本概念介绍    1.Redis是远程的，有客户端和服务端，我们一般说的是服务端；2.Redis是基于内存的，所以比基于硬盘的MySQL要快很多，但非常吃内存3.Redis是非关系型数据库。本质上也是数据库，但MySQL关系型数据库存储时必须定义数据词典，而Redis则不需要。1.2 Redis 和 Memcached比较        Redi...
Redis高级特性解析：持久化、主从复制与哨兵机制全面探讨
12-14
本文详细探讨了Redis的三大高级特性：持久化、主从复制和哨兵机制。首先，我们探讨了Redis的两种持久化方式：RDB和AOF。RDB通过定期生成数据快照来实现数据的持久化，而AOF则记录每个写操作，提供更强的数据安全性。...
Redis主从复制、持久化、哨兵
01-07
（一）Redis集群的主从复制 概念 主从备份，防止主机宕机 ...redis 是一个支持持久化的内存数据库，也就是说 redis 需要经常将内存中的数据同步到磁盘来保证持久化.redis 支持两种持久化方式，一种是 Snapsho
Redis持久化、主从与哨兵架构详解.pdf
03-18
主要介绍Redis持久化、主从与哨兵架构详解，详细具体，可操作性好！
Redis非关系型数据库笔记-数据持久化-主从同步-缓存-笔记-五大数据类型-三大特殊数据类型
02-26
主从同步：Redis支持主从同步，即可以将数据复制到任意数量的从服务器。这一特性使得Redis能够实现数据的备份和恢复，提高系统的可用性和可靠性。 Redis的应用场景非常广泛，包括但不限于： 缓存：Redis常被用作
Linux下redis的持久化、主从同步与哨兵详解
09-09
主要给大家介绍了关于Linux下redis的持久化、主从同步与哨兵的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
redis--消息队列
最新发布
m0_65342309的博客
05-23 260
生产者消费者模式下，多个消费者同时监听一个队里，但是一个消息只能被最先抢到消息的消费者消费，即消息任务是一次性读取和处理，此模式在分布式业务架构中非常常用，比较常用的软件还有RabbitMQ、Kafka、RocketMQ、ActiveMQ等队列当中的 消息由不同的生产者写入也会有不同的消费者取出进行消费处理，但是一个消息一定是只能被取出一次也就是被消费一次。
MySQL和Redis比较及两者结合运用
2302_77150007的博客
05-16 823
选择MySQL还是Redis取决于具体的应用需求。如果应用需要高速的数据访问和较低的资源消耗，Redis是一个很好的选择。而如果应用需要复杂的查询处理和高可靠性的数据持久性，MySQL则更为适合。那么长的比较帅/美的小伙伴就要问了。那我把两者结合不久好了。
分布式系统(一)-Redis
0x12的专栏
05-17 318
Redis作为当前主流的缓存组件，合理的运用将极大提高系统的性能。
Redis 缓存失效策略及其应用场景
以择人之心择己，以恕己之心恕人。
05-18 1855
Redis，作为一款高性能的键值存储系统，广泛应用于缓存、消息队列、计数器等多种场景中。其高效的数据管理和过期策略是保证系统稳定运行的关键因素之一。本文将深入探讨Redis中缓存失效的几种策略——定时删除、惰性删除、定期删除，以及如何结合LRU和LFU策略进行内存管理，并分析它们各自的应用场景，帮助开发者更好地根据实际需求选择合适的策略。
redis 持久化 主从复制 哨兵模式 雪崩击穿穿透区别和解决办法
08-11
Redis 持久化是指将内存中的数据保存到磁盘上，以防止服务器重启或者意外宕机时数据的丢失。Redis提供了两种持久化方式：RDB（Redis Database）和AOF（Append Only File）。 RDB是将当前内存中的数据快照保存到磁盘...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值