Redis事务、主从复制、哨兵机制

最新推荐文章于 2023-03-15 07:45:35 发布

做最幸福的

最新推荐文章于 2023-03-15 07:45:35 发布

阅读量1.5k

点赞数

分类专栏：笔记 redis 文章标签： java redis mysql

本文链接：https://blog.csdn.net/qq_44794280/article/details/123581761

版权

笔记同时被 2 个专栏收录

31 篇文章 1 订阅

订阅专栏

redis

1 篇文章 0 订阅

订阅专栏

目录结构如下所示

1. Redis 事务
2. 事务操作的命令 jdbc 数据库
3. 事务的实现
4. 持久化
5.主从复制
- 主从复制--读写分离
- - （1） Redis 主从复制实现（master/salve）
6.高可用 Sentinel 哨兵
7.安全设置
- A、开启访问密码设置
- B、访问有密码的 Redis

1. Redis 事务

事务是指一系列操作步骤，这一系列的操作步骤，要么完全地执行，要么完全地不执行。
Redis 中的事务（transaction）是一组命令的集合，至少是两个或两个以上的命令，redis 事务保证这些命令被执行时中间不会被任何其他操作打断。
redis事务其实是指运用事务的思想实现一组集合命令的执行，没有回滚的概念，严格意义上没有事务。

2. 事务操作的命令 jdbc 数据库

（1） multi - setAutoCommoit（false）-事务开启

语法： multi
作用：标记一个事务的开始。事务内的多条命令会按照先后顺序被放进一个队列当中。
返回值：总是返回 ok

（2） exec -执行

语法：exec
作用：执行所有事务块内的命令
返回值：事务内的所有执行语句内容，事务被打断（影响）返回 nil

（3） discard -取消

语法：discard
作用：取消事务，放弃执行事务块内的所有命令
返回值：总是返回 ok

（4） watch -监视某个或者某几个key的值的变化

语法：watch key [key …]
作用：监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
返回值：总是返回 ok

（5） unwatch –取消监视

语法：unwatch
作用：取消 WATCH 命令对所有 key 的监视。如果在执行 WATCH 命令之后， EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了
返回值：总是返回 ok

3. 事务的实现

（1）正常执行事务

事务的执行步骤：首先开启事务，其次向事务队列中加入命令，最后执行事务提交例 1：事务的执行:
1） multi ：用 multi 命令告诉 Redis，接下来要执行的命令你先不要执行，而是把它们暂时存起来（开启事务）
2） sadd works john 第一条命令进入等待队列（命令入队）
3） sadd works rose 第二条命令进入等待队列（命令入队）
4） exce 告知 redis 执行前面发送的两条命令（提交事务）
在这里插入图片描述
works 集合

（2）事务执行 exec 之前，入队命令错误（语法

错误；严重错误导致服务器不能正常工作（例如内存不足）），放弃事务。
执行事务步骤：
1） MULTI 正常命令
2） SET key value 正常命令
3） INCR 命令语法错误
4） EXEC 无法执行事务，那么第一条正确的命令也不会执行，所以 key 的值不会设置成功
在这里插入图片描述
**结论：事务执行 exec 之前，入队命令错误，事务终止，取消，不执行。 **

（3）事务执行 exec 命令后，执行队列命令，命令执行错误，事务提交

执行步骤：
1） MULTI 正常命令
2） SET username zhangsan 正常命令
3） lpop username 正常命令，语法没有错误，执行命令时才会有错误。
4） EXEC 正常执行 ,发现错误可以在事务提交前放弃事务，执行 discard.
在这里插入图片描述
结论：在 exec 执行后的所产生的错误，即使事务中有某个/某些命令在执行时产生了错误，事务中的其他命令仍然会继续执行

Redis 在事务失败时不进行回滚，而是继续执行余下的命令。
Redis 这种设计原则是：Redis 命令只会因为错误的语法而失败（这些问题不能在入队时发现），或是命令用在了错误类型的键上面，失败的命令并不是 Redis 导致，而是由编程错误造成的，这样错误应该在开发的过程中被发现，生产环境中不应出现语法的错误。就是在程序的运行环境中不应该出现语法的错误。而 Redis 能够保证正确的命令一定会被执行。再者不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

（4）放弃事务

执行步骤：

MULTI 开启事务
SET age 25 命令入队
SET age 30 命令入队
DISCARD 放弃事务，则命令队列不会被执行例 1：

（5） Redis 的 watch 机制

A、 Redis 的 WATCH 机制
WATCH 机制原理：
WATCH 机制：使用 WATCH 监视一个或多个 key , 跟踪 key 的 value 修改情况，如果有 key 的 value 值在事务 EXEC 执行之前被修改了，整个事务被取消。EXEC 返回提示信息，表示事务已经失败。

WATCH 机制使的事务 EXEC 变的有条件，事务只有在被 WATCH 的 key 没有修改的前提下才能执行。不满足条件，事务被取消。使用 WATCH 监视了一个带过期时间的键，那么即使这个键过期了，事务仍然可以正常执行 –key键过期，watch机制失效

大多数情况下，不同的客户端会访问不同的键，相互同时竞争同一 key 的情况一般都很少， 乐观锁能够以很好的性能解决数据冲突的问题。

B、何时取消 key 的监视（WATCH）？
① WATCH 命令可以被调用多次。 对键的监视从 WATCH 执行之后开始生效，直到调用 EXEC 为止。不管事务是否成功执行， 对所有键的监视都会被取消。
② 当客户端断开连接时， 该客户端对键的监视也会被取消。
③ UNWATCH 命令可以手动取消对所有键的监视

C、 WATCH 的事例
执行步骤：
首先启动 redis-server , 在开启两个客户端连接。分别叫 A 客户端和 B 客户端。
启动 Redis 服务器
A 客户端（红色）：WATCH 某个 key ，同时执行事务
B 客户端（黄色）：对 A 客户端 WATCH 的 key 修改其 value 值。

1）在 A 客户端设置 key : str.lp 登录人数为 10
2）在 A 客户端监视 key : str.lp
3）在 A 客户端开启事务 multi
4）在 A 客户端修改 str.lp 的值为 11
5）在 B 客户端修改 str.lp 的值为 15
6）在 A 客户端执行事务 exec
7）在 A 客户端查看 str.lp 值，A 客户端执行的事务没有提交，因为 WATCH 的 str.lp 的值已经被修改了，所有放弃事务。

例 1：乐观锁
在这里插入图片描述

在这里插入图片描述

4. 持久化

(1) 持久化概述

持久化可以理解为存储，就是将数据存储到一个不会丢失的地方，如果把数据放在内存中，电脑关闭或重启数据就会丢失，所以放在内存中的数据不是持久化的，而放在磁盘就算是一种持久化。

Redis 的数据存储在内存中，内存是瞬时的，如果 linux 宕机或重启，又或者 Redis 崩溃或重启，所有的内存数据都会丢失，为解决这个问题，Redis 提供两种机制对数据进行持久化存储，便于发生故障后能迅速恢复数据。

(2) 持久化方式

1） RDB 方式

A、什么是 RDB 方式?

Redis Database（RDB），就是在指定的时间间隔内将内存中的数据集快照写入磁盘，数据恢复时将快照文件直接再读到内存。
RDB 保存了在某个时间点的数据集（全部数据）。存储在一个二进制文件中，只有一个文件。默认是 dump.rdb。RDB 技术非常适合做备份，可以保存最近一个小时，一天，一个月的全部数据。保存数据是在单独的进程中写文件，不影响 Redis 的正常使用。 RDB 恢复数据时比其他 AOF 速度快。

B、如何实现?

RDB 方式的数据持久化，仅需在 redis.conf 文件中配置即可，默认配置是启用的。

在配置文件 redis.conf 中搜索 SNAPSHOTTING，查找在注释开始和结束之间的关于 RDB 的配置说明。配 SNAPSHOTTING 置地方有三处。

①：配置执行 RDB 生成快照文件的时间策略。
对 Redis 进行设置，让它在“ N 秒内数据集至少有 M 个 key 改动”这一条件被满足时，自动保存一次数据集。

配置格式：save save 900 1
save 300 10
save 60 10000

②：dbfilename：设置 RDB 的文件名，默认文件名为 dump.rdb
③：dir：指定 RDB 文件的存储位置，默认是 ./ 当前目录
配置步骤：
①：查看 ps -ef | grep redis ，如果 redis 服务启动，先停止。

在这里插入图片描述
②：修改 redis.conf 文件，修改前先备份，执行 cp redis.conf bak_redis.conf

查看默认启用的 RDB 文件

③：编辑 redis.conf 增加 save 配置，修改文件名等。vim redis.conf

修改的内容：

把原来的默认的 dump.rdb 删除，修改 redis.conf 后，重新启动 redis ④：在 20 秒内容，修改三个 key 的值
在这里插入图片描述
⑤：查看生成的 rdb 文件

C、总结

优点：由于存储的是数据快照文件，恢复数据很方便，也比较快，容灾备份
缺点：
1）会丢失最后一次快照以后更改的数据。如果你的应用能容忍一定数据的丢失，那么使用 rdb 是不错的选择；如果你不能容忍一定数据的丢失，使用 rdb 就不是一个很好的选择。
2）由于需要经常操作磁盘，RDB 会分出一个子进程。如果你的 redis 数据库很大的话，子进程占用比较多的时间，并且可能会影响 Redis 暂停服务一段时间（millisecond 级别），如果你的数据库超级大并且你的服务器 CPU 比较弱，有可能是会达到一秒。

2） AOF 方式

A、什么是 AOF 方式

Append-only File（AOF），Redis 每次接收到一条改变数据的命令时，它将把该命令写到一个 AOF 文件中（只记录写操作，读操作不记录），当 Redis 重启时，它通过执行 AOF 文件中所有的命令来恢复数据。

B、如何实现

AOF 方式的数据持久化，仅需在 redis.conf 文件中配置即可配置项：
①：appendonly：默认是 no，改成 yes 即开启了 aof 持久化
②：appendfilename：指定 AOF 文件名，默认文件名为 appendonly.aof
③：dir : 指定 RDB 和 AOF 文件存放的目录，默认是 ./
④：appendfsync：配置向 aof 文件写命令数据的策略：
no：不主动进行同步操作，而是完全交由操作系统来做（即每 30 秒一次），比较快但不是很安全。
always：每次执行写入都会执行同步，慢一些但是比较安全。
everysec：每秒执行一次同步操作，比较平衡，介于速度和安全之间。这是默认项。
⑤：auto-aof-rewrite-min-size：允许重写的最小 AOF 文件大小，默认是 64M 。当 aof 文件大于 64M 时，开始整理 aof文件，去掉无用的操作命令。缩小 aof 文件。

例 1：
①：停止运行的 redis ，备份要修改的 redis.conf
②：查看 redis 安装目录/src 下有无 .aof 文件。默认是在 redis 的当前目录
在这里插入图片描述
③：编辑 redis.conf 设置 appendonly 为 yes 即可。查看 appendfsync 的当前策略。
查看 appendfilname 的文件名称

④：在 redis 客户端执行写入命令

⑤ 查看 aof 文件

C）总结

1） append-only 文件是另一个可以提供完全数据保障的方案；
2） AOF 文件会在操作过程中变得越来越大。比如，如果你做一百次加法计算，最后你只会在数据库里面得到最终的数值，但是在你的 AOF 里面会存在 100 次记录，其中 99 条记录对最终的结果是无用的；但 Redis 支持在不影响服务的前提下在后台重构 AOF 文件，让文件得以整理变小
3）可以同时使用这两种方式，redis默认优先加载aof文件（aof数据最完整）；

5.主从复制

主从复制–读写分离

通过持久化功能，Redis 保证了即使在服务器重启的情况下也不会丢失（或少量丢失）数据，但是由于数据是存储在一台服务器上的，如果这台服务器出现故障，比如硬盘坏了，也会导致数据丢失。单点故障
为了避免单点故障，我们需要将数据复制多份部署在多台不同的服务器上，即使有一台服务器出现故障其他服务器依然可以继续提供服务。
这就要求当一台服务器上的数据更新后，自动将更新的数据同步到其他服务器上，那该怎么实现呢？ Redis的主从复制。
在这里插入图片描述
Redis 提供了复制（replication）功能来自动实现多台 redis 服务器的数据同步（每天
19 点新闻联播，基本从 cctv1-8,各大卫视都会播放）
我们可以通过部署多台 redis，并在配置文件中指定这几台 redis 之间的主从关系，主负责写入数据，同时把写入的数据实时同步到从机器，这种模式叫做主从复制，即 master/slave，并且 redis 默认 master 用于写，slave 用于读，向 slave 写数据会导致错误，从服务器主要负责读操作

（1） Redis 主从复制实现（master/salve）

方式 1：修改配置文件，启动时，服务器读取配置文件，并自动成为指定服务器的从服
务器，从而构成主从复制的关系
方式 2： ./redis-server --slaveof 主服务器Ip,主服务器端口，在启动 redis 时指定当前服务成为某个主 Redis 服务的从 Slave

方式 1 的实现步骤：模拟多 Reids 服务器，在一台已经安装 Redis 的机器上，运行多个 Redis 应用模拟多个 Reids 服务器。一个 Master，两个 Slave.

A、新建三个 Redis 的配置文件

如果 Redis 启动，先停止。
作为 Master 的 Redis 端口是 6380
作为 Slaver 的 Redis 端口分别是 6382 , 6384
从原有的 redis.conf 拷贝三份，分别命名为 redis6380.conf, redis6382.conf , redis6384.conf
在这里插入图片描述

B、编辑 Master 配置文件

编辑 Master 的配置文件 redis6380.conf : 在空文件加入如下内容
include /usr/local/redis/redis-3.2.9/redis.conf
daemonize yes
port 6380
pidfile /var/run/redis_6380.pid
logfile 6380.log
dbfilename dump6380.rdb

![在这里插入图片描述](https://img-blog.csdnimg.cn/70a64e690ca4473d8c7412b557cc8f9d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5YGa5pyA5bm456aP55qE,size_20,color_FFFFFF,t_70,g_se,x_16)

注意:redis内配置文件只能以key,value形式进行配置，不能多条写在一行，否则会出错。

配置项说明： include ：包含原来的配置文件内容。/usr/local/redis-3.2.9/redis.conf 按照自己的目录设置。 daemonize：yes 后台启动应用，相当于 ./redis-server & , &的作用。 port : 自定义的端口号 pidfile : 自定义的文件，表示当前程序的 pid ,进程 id。 logfile：日志文件名 dbfilename：持久化的 rdb 文件名 #### C、编辑 Slave 配置文件编辑 Slave 的配置文件 redis6382.conf 和 redis6384.conf: 在空文件加入如下内容 **①：redis6382.conf： include /usr/local/redis/redis-3.2.9/redis.conf daemonize yes port 6382 pidfile /var/run/redis_6382.pid logfile 6382.log dbfilename dump6382.rdb slaveof 127.0.0.1 6380**

配置项说明： slaveof ：表示当前 Redis 是谁的从。当前是 127.0.0.1 端口 6380 这个 Master 的从。

②：redis6384.conf：
include /usr/local/redis/redis-3.2.9/redis.conf
daemonize yes
port 6384
pidfile /var/run/redis_6384.pid
logfile 6384.log
dbfilename dump6384.rdb
slaveof 127.0.0.1 6380
在这里插入图片描述

D、启动服务器 Master/Slave 都启动

启动方式 ./redis-server 配置文件启动
Redis,并查看启动进程
在这里插入图片描述

E、查看配置后的服务信息

命令：
①： Redis 客户端使用指定端口连接 Redis 服务器
./redis-cli -p 端口
②：查看服务器信息
info replication

登录到 Master：6380
在这里插入图片描述

查看当前服务信息
在客户端的 Redis 内执行命令 info replication Master
服务的查看结果:
在这里插入图片描述

在新的 puty窗口分别登录到 6382 ，6384 查看信息
在这里插入图片描述

6384 也登录内容同 6382.

F、向 Master 写入数据

在 6380 执行 flushall 清除数据，避免干扰的测试数据。生产环境避免使用。
在这里插入图片描述

G、在从 Slave 读数据

6382,6384 都可以读主 Master 的数据，不能写
在这里插入图片描述

Slave 写数据失败
在这里插入图片描述

1.容灾处理

当 Master 服务出现故障，需手动将 slave 中的一个提升为 master，剩下的 slave 挂至新的master 上（冷处理：机器挂掉了，再处理）

命令：
①：slaveof no one，将一台 slave 服务器提升为 Master （提升某 slave 为 master）
②：slaveof 127.0.0.1 6382 （将 slave 挂至新的 master 上）

执行步骤：

A、将 Master:6380 停止（模拟挂掉）

在这里插入图片描述

B、选择一个 Slave 升到 Master，其它的 Slave 挂到新提升的 Master

在这里插入图片描述

C、将其他 Slave 挂到新的 Master

在 Slave 6384 上执行
在这里插入图片描述

现在的主从（Master/Slave）关系：Master 是 6382 ， Slave 是 6384 查看 6382：
在这里插入图片描述

D、原来的服务器重新添加到主从结构中

6380 的服务器修改后，从新工作，需要把它添加到现有的 Master/Slave 中先启动 6380 的 Redis 服务
在这里插入图片描述

连接到 6380 端口
在这里插入图片描述

当前服务挂到 Master 上
在这里插入图片描述

E、查看新的 Master 信息

在 6382 执行：
在这里插入图片描述

现在的 Master/Slaver 关系是：
Master: 6382
Slave: 6380 6384

（3）操作命令

进入客户端需指定端口：./redis-cli -p 6380 不配置启动默认都是主 master
info replication 查看 redis 服务器所处角色

（4）总结

1、一个 master 可以有多个 slave
2、 slave 下线，读请求的处理性能下降
3、 master 下线，写请求无法执行
4、当 master 发生故障，需手动将其中一台 slave 使用 slaveof no one 命令提升为 master，其它 slave 执行 slaveof 命令指向这个新的 master，从新的 master 处同步数据
5、主从复制模式的故障转移需要手动操作，要实现自动化处理，这就需要 Sentinel 哨兵，实现故障自动转移

6.高可用 Sentinel 哨兵

Sentinel 哨兵是 redis 官方提供的高可用方案，可以用它来监控多个 Redis 服务实例的运行情况。Redis Sentinel 是一个运行在特殊模式下的 Redis 服务器。Redis Sentinel 是在多个 Sentinel 进程环境下互相协作工作的。

Sentinel 系统有三个主要任务：

监控：Sentinel 不断的检查主服务和从服务器是否按照预期正常工作。
提醒：被监控的 Redis 出现问题时，Sentinel 会通知管理员或其他应用程序。
自动故障转移：监控的主 Redis 不能正常工作，Sentinel 会开始进行故障迁移操作。将一个从服务器升级新的主服务器。让其他从服务器挂到新的主服务器。同时向客户端提供新的主服务器地址。

（1） Sentinel 配置

1）Sentinel 配置文件

复制三份sentinel.conf文件：
Sentinel系统默认 port 是26379 。三个配置port分别设置为 26380 , 26382 , 26384 。三个文件分别命名：

sentinel26380.conf
sentinel26382.conf
sentinel26384.conf 执行复制命令 cp sentinel.conf xxx.conf

（2）三份 sentinel 配置文件修改：

1、修改 port 26380、 port 26382、 port 26384
2、修改 sentinel monitor mymaster 127.0.0.1 6380
2 格式：sentinel monitor 主redis名称、主redisIp 、主redis端口号 <Quorum 投票数>

Sentinel监控主(Master)Redis, Sentinel根据Master的配置自动发现Master的Slave,Sentinel 默认端口号为26379 。
在这里插入图片描述
sentinel26380.conf

修改 port

请注意，哨兵在下面这行代码中所选取的master的端口要一致，要不然哨兵无法同步。(初学者注意)

sentinel26382.conf 修改port 26382 , master的port 6382 sentinel26384.conf 修改port 26384 , master的port 6380

（3）启动主从（Master/Slave）Redis

启动 Reids
在这里插入图片描述
查看 Master 的配置信息连接到 6380 端口 ,使用 info 命令查看 Master/Slave

（4）启动 Sentinel

redis安装时make编译后就产生了redis-sentinel程序文件，可以在一个redis中运行多个 sentinel进程。

启动一个运行在Sentinel模式下的Redis服务实例
./redis-sentinel sentinel 配置文件

执行以下三条命令，将创建三个监视主服务器的Sentinel实例：
./redis-sentinel …/sentinel26380.conf
./redis-sentinel …/sentinel26382.conf
./redis-sentinel …/sentinel26384.conf
在 XShell 开启三个窗口分别执行：
在这里插入图片描述

在这里插入图片描述

（5）主 Redis 不能工作

让 Master 的 Redis 停止服务，执行 shutdown 先执行 info replication 确认 Master 的 Redis ，再执行 shutdown
在这里插入图片描述
查看当前 Redis 的进程情况

（6） Sentinel 的起作用

在 Master 执行 shutdown 后，稍微等一会 Sentinel 要进行投票计算，从可用的 Slave
选举新的 Master。查看 Sentinel 日志，三个 Sentinel 窗口的日志是一样的。
在这里插入图片描述

查看新的 Master
在这里插入图片描述

查看原 Slave 的变化
在这里插入图片描述

（7）新的 Redis 加入 Sentinel 系统，自动加入 Master

重新启动 6380
在这里插入图片描述

查看 6382 的信息
在这里插入图片描述

测试数据：在 Master 写入数据
在这里插入图片描述

在 6382 上读取数据，不能写入
在这里插入图片描述

（8）监控

1） Sentinel 会不断检查 Master 和 Slave 是否正常
2）如果 Sentinel 挂了，就无法监控，所以需要多个哨兵，组成 Sentinel 网络，一个健康的
Sentinel 至少有 3 个 Sentinel 应用。彼此在独立的物理机器或虚拟机。
3）监控同一个 Master 的 Sentinel 会自动连接，组成一个分布式的 Sentinel 网络，互相通信并交换彼此关于被监控服务器的信息
4）当一个 Sentinel 认为被监控的服务器已经下线时，它会向网络中的其它 Sentinel 进行确认，判断该服务器是否真的已经下线
5）如果下线的服务器为主服务器，那么 Sentinel 网络将对下线主服务器进行自动故障转移，通过将下线主服务器的某个从服务器提升为新的主服务器，并让其从服务器转移到新的主服务器下，以此来让系统重新回到正常状态
6）下线的旧主服务器重新上线，Sentinel 会让它成为从，挂到新的主服务器下

（9）总结

主从复制，解决了读请求的分担，从节点下线，会使得读请求能力有所下降，Master 下线，写请求无法执行

Sentinel 会在 Master 下线后自动执行故障转移操作，提升一台 Slave 为 Master，并让其它
Slave 成为新 Master 的 Slave

7.安全设置

访问 Redis 默认是没有密码的，这样不安全，任意用户都可以访问。可以启用使用密码才能访问 Redis。设置 Redis 的访问密码，修改 redis.conf 中这行 requirepass 密码。密码要比较复杂，不容易破解，而且需要定期修改。因为 redis 速度相当快，所以在一台比较好的服务器下，一个外部的用户可以在一秒钟进行 150K 次的密码尝试，需要指定非常非常强大的密码来防止暴力破解。

A、开启访问密码设置

修改 redis.conf , 使用 vim 命令。找到 requirepass 行去掉注释，requirepass 空格后就是密码。
例 1：设置访问密码是 xx,这是练习使用，生产环境要设置复杂密码修改 redis.conf，文件 480 行左右。原始内容：
（ps:可以通过/name来进行搜索）
在这里插入图片描述
修改后：

查看修改结果：
注意requirepass前面注释记得放开才会生效
未放开

已放开