您好,欢迎访问代理记账网站
移动应用 微信公众号 联系我们

咨询热线 -

电话 15988168888

联系客服
  • 价格透明
  • 信息保密
  • 进度掌控
  • 售后无忧

5redis------------redis 进阶---Redis事务、Redis 管道技术、redis持久化、Redis主从复制、哨兵模式-----全栈式开发43

redis进阶知识

  • 一、事务
    • (一) 事务介绍
    • (二) 事务操作
  • 二、管道技术——Pipeline
    • (一)介绍
    • (二)实现管道技术
  • 三、redis持久化
    • (一)RDB
        • 1.1手动触发---操作命令
        • 1.2自动触发---配置文件修改
    • (二)AOF
        • 2.1手动触发
        • 2.2自动触发
  • 四、主从复制
  • 五、sentinel哨兵模式

一、事务

(一) 事务介绍

前言

  • 事务指的是提供一种将多个命令打包,一次性按顺序地执行的机制,并且保证服务器只有在执行完事务中的所有命令机制后,才能继续处理客服端的其它命令。
  • 事务也是其它关系型数据库所必备的基础功能,以支付的场景为例,正常情况下只有正常的消费完成之后,才会减去账户余额。但是没有事务的保障,可能会发生消费失败了,但依旧会把账户的余额给扣减了,我想这种情况下应该任何人都无法接受吧?所以事务是数据库中一项非常重要的基础功能。
Redis事务mysql
执行步骤开启事务、命令入行、执行事务/放弃事务开启事务、执行业务代码、提交事务(业务处理出现异常,回滚事务)
没有锁,其他客户端可正常执行有着各自各样的来确保事务正常运行

Redis事务为什么不支持回滚?

  • Redis事务在执行时,错误通常都是编程错误造成的,这种错误通常只会出现在开发环境中,而很少会在实际的生产环境中出现,所以他认为没有必要为 Redis 开发事务回滚功能。
  • 不支持事务回滚是因为这种复杂的功能和 Redis 追求简单高效的设计主旨不符合。
  • 这里不支持事务回滚,指的是不支持运行时错误的事务回滚。

事物错误&回滚

  • 事物执行中的错误分为以下三类:
    • multi 命令不能嵌套使用,不会终止整个事物;
    • 命令语法错误,不会终止整个事物;
    • 命令不存在,则无法提交

(二) 事务操作

multi 开启事务

  • multi 命令可以让客服端从非事物 模式状态,变为事物模式状态。
  • multi 命令不能嵌套使用,如果已经开启了事物的情况下,再执行 multi,会提示如下错误:(error) ERR MULTI calls can not be nested,但不会终止客户端为事务的状态。

命令入列

  • 客户端进入事物装填之后,执行的所有常规 Redis 操作命令(非触发事物执行或放弃和导致入列异常的命令)会一次入列,命令入列成功后会返回 QUEUED,看不到命令执行结果,统一提交,统一显示执行结果
  • 命令会提示按照先进先出(FIFO)的顺序出入列,也就是说事物会按照命令的入列顺序,从前往后依次执行行。
  • 在没有被提交命令的时候,执行的命令并不会影响数据库,所以在其他客户端看不到修改的过程
    在这里插入图片描述

exec执行事务

  • 提交成功后会一并打包显示事务内的操作命令结果
  • 如果提交失败:(error) EXECABORT Transaction discarded because of previous errors.
    在这里插入图片描述

discard放弃事务

  • 动放弃事务

二、管道技术——Pipeline

(一)介绍

定义

  • 管道技术(Pipeline)是客户端提供的一种批处理技术,用于一次处理多个 Redis 命令,从而提高整个交互的性能。
  • 通常情况下 Redis 是单行执行的,客户端先向服务器发送请求,服务端接收并处理请求后再把结果返回给客户端,这种处理模式在非频繁请求时不会有任何问题。
  • 但如果出现几种大批量的请求时,因为每个请求都要经历请求再响应给客户端,这样就能大大的提升了 Redis 的响应速度
  • 但要注意的一点是,管道技术本质上是客户端提供的功能,而非 Redis 服务器端的功能,可以通过pycharm等客户端进行演示。
    在这里插入图片描述
    作用
  • 管道技术解决了多个命令集中请求时造成网络资源浪费的问题,加快了 Redis 的响应速度,让拥有更高的运行速度。

注意事项

  • 发送的命令数量不会被限制,但输入缓存区也就是命令的最大存储体积为 1 GB,当发送的命令超过此限制,命令不会被执行,并且会被 Redis 服务器端断开链接;
  • 如果管道的数据过多可能会导致客户端的等待时间过长,导致网络阻塞;
    部分客户端自己本身也有缓存区大小的设置,如果管道命令没有执行或者是执行不完整,可以排查此情况或较少管道内的命令重新尝试执行。

(二)实现管道技术

```
import redis
import time

r=redis.StrictRedis(host='127.0.0.1',port=6379)

t1=time.time()

# 创建管道
pl=r.pipeline()

res=pl.get('k-1')
print(res)
#
# for i in range(100):
#     pl.set('k-%s' % i,'v-%s' %i)

resl=pl.set('name','juran')
print(resl)

# 执行
pl.execute()

t2=time.time()
print(t2-t1)
```

小结

  • 使用管道技术可以解决多个命令执行时的网络等待,它是把多个命令整合到一起发送给服务器端处理之后统一返回给客户端,这样就免去了每条命令执行后都要等待的情况,从而有效地提高了程序的执行效率,但使用管道技术也要注意避免发送的命令过大,或管道内的数据太多而导致的网络阻塞。

三、redis持久化

定义

  • redis的读写都是在内存中,所以它的性能较高,但在内存中的数据会随着服务器的重启二丢失,为了保证数据不丢失,我们需要将内存中的数据存储到磁盘,一边redis重启时,能够从磁盘中回复原有的数据,而整个过程就叫做redis的持久化
    在这里插入图片描述

作用

  • 为了保证数据不丢失

持久化开启方法

  • RDB(redis database)快照方式。
  • AOF(append only file)文件追加方式。
  • 混合持久化方式。选这个最优。4.0之后新增的方式,混合持久化结合了RDB和AOF的优点,在写入的时候,现将先前的数据以RDB的形式写入文件的开头,再将后续的操作命令以AOF的格式存入文件,这样既能保证redis重启时的速度,又能减低数据丢失的风险
    在这里插入图片描述

(一)RDB

RDB定义

  • 将某一个时刻的内存数据,保存状态,以二进制的方式写入磁盘RDB文件里
  • flushall命令用于清空redis数据库,子生产环境下一定要慎用,当redis执行了flushall命令之后,则会触发自动持久化,把RDB文件清空

持久化触发方法

  • 手动触发:save、bgsave命令
  • 自动触发:修改save配置

RDB优缺点

  • 优点
    • RDB的呢绒为二进制的数据,占用内存小,更紧凑,更适合做 备份文件
    • RDB对灾难恢复非常有用,它是一个紧凑的文件,可以更快的传输到远程服务器进行redis服务恢复
    • RDB可以更大程度提高redis的运行速度,因为每次持久化redis主进程都会fork()一个子进程,进行数据持久化到磁盘,redis主进程髌骨会执行磁盘I/O等操作
    • 与AOF格式的温家安相比,RDB文件可以更快的重启
  • 缺点
    • 因为RDB只能保存某个时间间隔的数据,如果中途redis服务被意外终止了,则会丢失一段时间内的redis数据
    • RDB需要进程fork()才嫩使用子进程将其持久化在磁盘上,如果数据集很大,fork()可能很耗时,并且如果数据集很大且CPU性能不佳,则可能导致redis停止为客户端服务几毫秒甚至一秒钟
    • 某一时刻,不是时时刻刻,会有文件丢失

1.1手动触发—操作命令

  • 手动触发持久化的操作有两个:save和bgsave
  • 区别主要体现在是否阻塞redis主线程的执行:save阻塞 bgsave不阻塞

save

  • 阻塞保存。save命令在客户端执行save命令,就会触发redis的持久化,但同时也是使redis处于阻塞的状态,直到RDB持久化完成,才会响应其他客户端发来的命令,所以在生产环境一定要慎用
    -- 查看rdb文件最新修改时间
    ls dump-rdb   -l
    -- 手动触发持久化,触发一次保存一次,机械
    save
    

bgsave

  • 后台保存。它和save命令最大的区别就是bgsave会fork()一个子进程来执行持久化,整个过程中只有fork()子进程时候有短暂的注释,当子进程被创建之后,redis的主进程就可以响应其他客户端的请求了,相对于整个流程都阻塞的save命令来说,显然bgsave命令更适合我们使用
    -- 查看rdb文件最新修改时间
    ls dump-rdb   -l
    -- 手动触发持久化
    bgsave
    

1.2自动触发—配置文件修改

save m n

  • m秒内,如果有n个键key发生变化,则自动触发bgsave命令。
  • save 60 1 表明在60秒内,如果有一个键发生改变,就会触发RDB持久化。
  • save m 0 就是间隔m时间自动保存
       #   -----linux操作-------
       -- 编辑配置文件,在redis文件夹下
       vim redis.conf
       -- 修改save
       save m n 
       stop-writes-on-bgsave-error yes #[可选] bgsave失败之后,停止持久化到磁盘
       rdbcompression yes #[可选] RDB文件压缩
       rdbchecksum yes #[可选] 写入文件和读取文件时开启RDB文件检查,检查是否有损,如果咋启动时检查发现损坏,则停止启动
       dbfilename dump.rdb # [可选]修改rdb文件名
       dir 路径  # [可选]修改rdb存储路径
       -- 重启redis,生效配置文件
       SHUTDOWN
       exit
       ps -aux | grep redis  # 查看是否关闭
       src/redis-server redis.conf  #开启服务器
       src/redis-cli #连接
       ```
    
    

(二)AOF

AOF命令

  • 记录所有操作的命令,并以文本的形式追加到文件中。AOF可以把redis每个键值对操作都记录到文件中

持久化触发方法

  • 首先开启AOF功能
    # linux下查询AOF是否启动
    config get appendonly
    # l开启AOF
    config set appendonly  yes # 命令行或者修改配置文件
    
  • 触发:手动触发、自动触发

AOF 文件重写

  • 保存最终状态
  • AOF文件重写是生成一个全新的文件,并把当前数据的最少操作命令保存到新文件上,当所有数据都保存到新文件之后,redis会交换两个文件,并把最新的持久化操作命令追加到新文件上
  • 引入原因:文件时通过记录redis的执行命令来持久化(保存)数据的,所以随着时间的流逝,AOP文件会越来越大,这样不仅能增加了服务器的存储压力,也会造成redis重启熟读不变慢,redis就是保存最终状态,而不是保存每条操作数据
  • 触发文件重写满足的条件:
  • auto-aof-rewrite-min-size:允许AOF重写的最小文件容量,默认4mb
  • auto-aof-rewrite-percentage:AOF文件重写的大小比例,默认值100,表示100%,也就是只有当前AOF文件,比最后一次(上一次)AOF文件大一倍时,才会启动AOF文件重写

AOF优缺点

  • 优点
    • AOF保存的数据更加完整
    • 采用的的命令追加的写入方式,不会出现文件损坏的问题,即使由于某些意外原因,导致了最后操作的持久化数据写了一半,也可以通过redis-check-aof工具轻松修复
    • AOF持久化文件,非常容易理解和解析,它是所有redis键值操作命令,以文件的方式写入磁盘。即使不小心使用了flushall删除了所有信息,只要使用AOF文件,删除最后的flushall命令,重启redis即可恢复之前误删的数据
  • 缺点
    • 对于相同的数据集来说,AOF文件要大于RDB文件
    • redis负载比较高的情况下,RDB比AOF性能更好
    • RDB使用快照的形式来持久化整个redis数据,而AOF只是将每次执行的命令追加到AOF文件中,因此RDB更加健壮

2.1手动触发

  • bgrewriteaof

2.2自动触发

  • redis.conf 配置参数和说明
    # 是否开启 AOF,yes 为开启,默认是关闭
    appendonly no
    
    # AOF 默认文件名
    appendfilename 'appendonly.aof'
    
    # AOF 持久化策略配置
    # appendfsync always
    appendfsync everysec
    appendfsync no
    	**always**
    	- 每条redis操作命令都会写入磁盘,最多丢失一条数据
    	**everysec**
    	-  默认开启
    	- 每秒钟写入一次数据,最多丢失一秒数据
    	**no**
    	- 不设置写入磁盘的规则,根据当前操作系统来决定何时写入磁盘,linux默认30S写入一次数据
    # AOF 文件重写的大小比例,默认值是100,表示100%,也就是只有当前 AOF 文件,比最后一次的 AOF 文件大一倍时,才会启动 AOF 文件重写。
    auto-aof-rewritre-percentage 100
    
    # 允许 AOF 重写的最小文件容量
    auto-aof-rewrite-min-size 64mb
    
    # 是否开启启动加载 AOF 文件效验,默认值是yes,表示尽可能的加载 AOF 文件,忽略错误部分信息,并启动 Redis 服务,
    
    # 如果值为 no,则表示,停止启动 Redis,用户必须手动修复 AOF 文件才能正常启动 Redis 服务。
    aof-load-truncated yes
    

四、主从复制

引入

  • Redis的持久化保证了即使Redis服务重启也不会丢失数据,因为Redis服务重启后会将硬盘上持久化的数据恢复到内存中,但是当Redis服务器的硬盘损坏了可能会导致数据丢失,不过通过Redis的主从复制机制就可以避免这种单点故障
  • 一个master 可以拥有多个slave,一个slave又可以拥有多个slave,如此下去,形成了强大的多级服务器集群架构
  • master用来写数据,slave用来读数据,经统计:网站的读写比率是 10:1
    通过只从配置可以实现读写分离,正常生产环境是接近10:1
  • master和slave都是一个redis实例(redis服务)。
    在这里插入图片描述
    	'''
    	主机
    	'''
    ## 修改 etc/redis.conf文件
    bind 0.0.0.0 ## 或者改成本机IP
    ## 开启主机服务
    src/redis-server redis.conf
    # 进入主客户端
    src/redis-cli -h 主机端口 -p 6379
    # 在master上写数据
    	'''
    	从机
    	'''
    ## 复制etc/redis/redis.conf 文件
    cp redis.conf slave.conf
    vim slave.conf
    ## 修改redis/slave.conf 文件
    bind +(主机ip)
    slaveof 主机ip 6379 (主机端口)
    port 6378 (从机端口)
    ## 开启从机服务
    src/redis-server slave.conf
    ## 进入从的客服端
    src/redis-cli -h 主机ip  -p 6378
    # 在slave 上读数据
    

五、sentinel哨兵模式

定义

  • 自动故障转移, 当主服务器挂掉,在从机会随机挑一个顶替成为主机,接替工作,还可以设置多个哨兵监察
  • sentinel系统可以监视一个或者多个redis master服务,以及这些master服务的所有从服务;当某个master服务下线时,自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

开启哨兵模式

  • 至少1主2从
    # 一般不需要修改配置文件
    vim sentinel.conf
    # mymaster 给监视的主机的名字,1主机的数量
    sentinel monitor mymaster 127.0.0.1 6379 1
    ## 运行配置文件
    src/redis-sentinel sentinel.conf
    ## 测试,主动干掉主机进程
    ps -aux | grep redis
    kill -9 14455
    ps -aux | grep redis
    role
    

分享:

低价透明

统一报价,无隐形消费

金牌服务

一对一专属顾问7*24小时金牌服务

信息保密

个人信息安全有保障

售后无忧

服务出问题客服经理全程跟进