redis进阶

事物

简介

redis事务可以一次执行多个命令,(按顺序的串行话执行,执行中不会被其它命令插入,不许加塞)

并且带有以下俩个主要的保证

批量操作在发送exec命令前被放入队列缓存

收到exec命令后进入事务执行,事务中任意命令执行失败,其余的命令依然被执行

在事务执行过程中,其他客户端提交的命令请求不会插入到事务执行命令序列中

redis会将一个事务的所有命令序列化,然后按顺序执行

执行中不会被其它命令插入,不允许出现加塞行为

常用命令

discard:取消事物
exec:执行所有事物模块内的命令
multi:标记一个事务模块的开始
watch (key) [key ...]:监视一个或多个key,如果事物执行之前这些key被其他命令改动,那么事务将被打断
unwatch:取消watch命令对所有key的监视

一个事务从开始到执行会经历这三个阶段:开始事物-》命令入队-》执行事物

discard放弃队列执行

输入milti开始,输入的命令都会一次进入队列中单不会执行

直到输入exec后,redis会将之前的命令队列中的命令依次执行。

命令队列的过程中可以通过discard来放弃队列执行

事务的错误处理

事务的错误处理,如果执行的某个命令报了错误,则只有报错的命令不会被执行,而其他命令都会执行,不会回滚

队列中的某个命令出了报告错误,执行时整个的队列都会被取消

watch (key) [key ...]:监视一个或多个key,如果事物执行之前这些key被其他命令改动,那么事务将被打断
unwatch:取消watch命令对所有key的监视

分布式锁

使用setnx设置一个公共锁

setnx (lock-key) (value)

利用setnx命令的返回值特征,有值则返回设置失败,物质则返回设置成功

对于返回设置成功的,拥有控制权,进行下一步的具体业务操作

操作完毕通过del操作释放锁

del (key)

死锁

依赖分布式锁的机制,某个用户操作时对于客户端宕机了,此时已经获取到锁了,如何解决

解决方法

expire为锁key添加时间限定,到时不释放,放弃锁

expire (key) (time) 设置锁,第二个参数是锁的时间
pexpire (key) (毫秒)

由于操作通常都是毫秒级为妙计,因此该锁设定时间不宜过大,.具体时间需要业务测试后确认

  • 如:尺有所的操作最长执行时间127ms,最短执行时间7ms
  • 测试百万次最长执行时间对于命令的最大耗时,测试百万次网络平均耗时
  • 锁时间设定推荐:最大耗时120%+平均网络延迟110%
  • 如果业务最大耗时<<网络延迟,通常为2个数量级,取其中单个耗时较长即可

redis持久化机制

什么是redis持久化

持久化就是把内存的数据写到磁盘中去,防止服务宕机了内存数据丢失

redis提供了俩种持久化方式RDB(默认)和AOF

简介

数据存放于:

内裤内存:搞笑,断电(关机)内存数据会丢失

硬盘:读写速度慢于内存,断电数据不会丢失

  • RDB一定时间读取存储文件
  • AOF默认每秒去存储历史命令

redis是支持持久化的内存数据库,也就是说redis需要经常讲内存中的数据同步到硬盘来保证持久化

RDB

rdb是redis database缩写

功能核心函数rdbsave和rdbloal俩个函数

rdb是redis默认的持久化机制,将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb

有点:快照保存数据几块,还原数据极快

适用于灾难备份

缺点:小机器不适合使用rdb,rdb机制符合要求就会照快照

快照条件

服务器正常关闭时 ./bin/rdids-cli shutdown
key满足一定条件会进行快照
vim redis.conf搜索save
save 900 1 //每900秒(15分钟)至少1个key发生变化,产生快照
save 300 10 //每300秒(5分钟)至少10个key发生变化,产生快照
save 60 10000 //没60秒(1分钟)至少10000个key发生变化,产生快照

AOF

由于快照方式是在一定间隔时间做一次的,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话,可以采用aof持久化方式

aof持久化时,redis会将每一个收集到的命令都通过write函数追加到文件中。当redis重启时,会通过重新执行文件中保存的命令来在内存中重建整个数据库的内容

每当之星服务器(定时)任务或者函数时flushAppendOnlyFile函数都会被调用,这个函数执行以下俩个工作

write:根据条件,将aof_buf中的缓存写入到文件

save:根据条件,的调用fsync或fdatasync函数,将aof保存到磁盘中

启用

redis.conf 编辑

appendonly yes //启用aof持久化方式

appendfsync always //收到命令就立即写入磁盘,最慢,但是保证完全的持久化

appendfsynceverysec//每秒钟写入磁盘一次,在性能和持久化方面做了很好的折中

appendfsync no //完全依赖os,性能最好,持久化没有保障

问题

aof的方式也同事带来了一个问题。持久化文件会变得越来越大。列入我们调用incr test命令一百次,文件中必须保存全部的100条命令,其实有99条都是多余的

数据删除策略

定时删除

  • 创建一个定时器,当key设置有过期时间,且过期时间到达时,有定时器任务立即执行对键的删除操作
  • 优点:节约内存,到时就删除,快速释放掉不必要的空间
  • 缺点cpu压力很大,无论cpu此时负载量多高,均占用cpu,会影响redis服务器响应时间和指令吞吐量

拿时间换空间

惰性删除

  • 时间到期后不作处理.等下次访问该数据时删除

    • 如果未过期,返回数据
    • 发现已过期,删除,返回不存在
  • 优点:节约cpu性能,发现必须删除的时候才删除
  • 缺点:内存压力很大,出现长期占用内存的数据
  • 总结:用存储空间换区处理器性能

空间换时间

定期删除

Redis 默认会每秒进行十次过期扫描(100ms一次),过期扫描不会遍历过期字典中所有的 key,而是采用了一种简单的贪心策略。

从过期字典中随机 20 个 key;

删除这 20 个 key 中已经过期的 key;

如果过期的 key 比率超过 1/4,那就重复步骤 1;

策略内存cpu
定时删除节约内存,无占用部分时段占用cpu资源,频度高
惰性删除内存占用严重延时执行,cpu利用率高
定期删除内存定期随机清理每秒花费固定的cpu资源维护内存

逐出算法

redis使用内存存储数据,在执行每一个命令前,会调用dreeMemoryfNeeded()检测内存是否充足.如果内存不满足新加入数据的最低存储要求,redis要临时删除一些数据为当前指令清理存储空间,情侣数据的策略称为逐出算法

主语:逐出数据的过程不是100%能够清理出足够使用的内存空间,我如果不成功则反复执行.当对所有数据尝试完毕后,如果不能达到内存的清理需求,将出现错误信息

数据删除策略

  • 最大可使用内存

maxmemory

占用物理内存的比例,默认值为0,表示不限制.生产环境中根据需求设定,通常在50%以上

  • 每次选取待删除数据的个数

maxmemory-samples

选取数据时并不会扫描全库,导致严重的性能消耗,降低读写性能.因此采用随机获取数据的方式作为待检测删除数据

  • 删除策略

maxmemory-policy

达到最大内存之后,对被挑选出来的数据进行删除的策略

数据逐出策略

maxmemory-policy volatile -Iru

  • 驱逐策略

检测易失数据(可能会过期的数据集server.db[i].expires )

volatile -Iru:挑选最近最少使用的数据淘汰

volatile-lfu:挑选最近使用次数最少的数据淘汰

volatile-ttl:挑选将要过期的数据淘汰

volatile-random:任意选择数据淘汰

  • 检测全库数据(所有数据集server.db[i].dict )

allkeys-lru:挑选最近最少使用的数据淘汰

allkeys-lfu:挑选最近使用次数最少的数据淘汰

allkeys-random:任意选择数据淘汰

  • 放弃数据驱逐

no-enviction (驱逐) :禁止驱逐数据(redis4.0中默认策略) ,会弓|发错误OOM (OutOf Memory)

主从复制

简介

redis高可用

单机redis的风险与问题

问题1.及其故障,系统崩溃

  • 现象:硬盘故障系统崩溃
  • 数据丢失,很可能对业务造成灾难性打击
  • 结论:基本上会放弃使用redis

问题2:容量瓶颈

  • 现象:内存不足,从16g升级到64g,从64升级到128g无线升级内存
  • 本质,硬件条件跟不上
  • 结论:放弃redis

为了避免单点redis服务区故障,准备多台服务器,互相炼铜。将数据复制多个副本保存在不同服务器上,连接在一起,并保证数据是同步的。即使其中有一台机器宕机,其他服务器依然可以继续提供服务,实现redis高可用,同时实现数据冗余备份

多台服务器连接方案

  • 提供数据方master

主服务器,主节点,主库

主客户端

  • 接受数据方:slave

从服务器,从节点,从库

从客户端

  • 解决的问题:数据同步
  • 核心工作:matser的数据复制到slave中

主从复制的作用

  • 读写分离matser写,slave读,提高服务器的读写能力
  • 负载均衡:基于主从结构,配合读写分离,由slave分担master负载,并根据需求的变化,改变slave的数量,通过多个节点分担数据读取负载,大大提高redis服务器并发与数据吞吐量
  • 故障恢复:当matser出现问题时,有slave提供服务,实现快速的故障恢复
  • 数据龙玉:实现数据热备份,是持久化之外的一种数据冗余方式
  • 高可用基石:基于主从复制,构建哨兵模式与集群,实现redis的高可用方案

工作流程

总述

主从复制大体可分为三个阶段

  • 建立连接阶段(即准备阶段)
  • 数据同步阶段
  • 命令传播阶段

建立连接

1.设置master的地址和端口,保存master信息

2.建立socket连接

3.发送ping命令(定时器任务)

4.身份验证

5.发送slave端口信息

至此,主从复制连接成功

状态:

slave:保存master的地址与端口

master:保存slave的端口

总体:之间创建了连接的socket

连接方式

客户端发送命令

slaveof<masterip> <masterport>

启动服务器参数

redis-server --slaveof <masterip><masterport>

服务器配置

slaveof <masterip><masterport>

数据同步

数据同步阶段工作流程

  • 请求同步数据
  • 创建rdb同步数据
  • 恢复rdb同步数据
  • 请求部分同步数据
  • 恢复部分同步数据

状态:

slave:具有master端全部数据,包含RDB过程接收的数据

master保存slave当前数据同步的位置

总体:完成了数据克隆

master

  • 如果master数据量巨大,数据同阶段应避开流量高峰期,避免造成master阻塞,影响业务正常执行
  • 复制缓冲区大小设定不合理,会导致数据溢出。如果进行全量复制周期太长,进行部分复制时发现数据已经存在丢失的情况,必须进行二次全量复制,使slave陷入死循环状态

repl-backlog-size 1mb(默认)

  • master占用主机内存的比例不应过大,建议使用50%-70%的内存,留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区

slave

  • 为必买nslave进行全量复制,部分复制是服务器相应阻塞或数据不同步,建议关闭此期间的对外服务
slave-serve-state-data yes|no
  • 数据同步阶段,master发送给slave信息可以理解master是一个slave的一个客户端,主动slave发送命令
  • 多个slave同时对master请求数据同步,master发送的rdb文件增多,会对带宽造成巨大冲击,如果master贷款不足,因此数据同步需要根据业务需求,适量错峰
  • slave过多时,建议调整拓步结构,有一主多从结构变为树状结构,中间的节点即是master,也是slave。注意使用树状结构,由于层级深度,导致深度越高的slave与最顶层的master间数据同步延迟较大,数据一致性变差,应该谨慎选择。

命令传播阶段

  • 当master数据库状态被修改后,导致主从服务器数据库状态不一致,此时需要让主从数据同步到一致的状态,同步的动作称为命令传播
  • master将接收到的数据变更命令发送给slave,slave接收命令后执行命令

命令传播阶段出现了断网

网络山断闪连 忽略

  • 短时间网络中断 部分复制
  • 长时间网络中断 全量复制

部分复制的三个核心要素

  • 服务器运行id(run id)
  • 主服务器的复制挤压缓冲区
  • 主服务器的复制偏移量
运行id

概念:服务器运行id是每一台服务器每次运行的身份识别码,一台服务器多次运行可生成多个运行id

组成:运行id有40为字符组成,是一个随机的16进制字符

作用:运行id被用于在服务器间进行传输,识别身份如果俩次操作均对同一台服务器进行,必须每次操作携带对应的运行id,用于对方识别

实现方式:运行id在每台服务器启动时自动生成,master首次连接slave,会将自己的运行id发送给slave,slave保存批id,通过info server命令可以查看节点的run id

复制缓冲区

组成:偏移量,字节值

工作原理

  • 通过offset区分不同的slave当前数据传播的差异
  • master记录已发送的信息对应的offset
  • slave记录接受的信息对应的offset

概念

复制缓冲区又名复制积压传冲去,是一个先进先出的队列,用于存储服务器执行过的命令,每次传播命令,master都会将传播的命令记录下来,并存储在复制缓冲区

复制缓冲区默认数据存储空间大小是1m,由于存储空间大小是固定的,当入队元素的数量大于队列长度时,最先入读id元素会被弹出,而新元素会被放入队列

由来:每台服务器启动时,如果开启有aof或被连接成为master节点,及创建复制缓冲区

作用:用于保护master收到的所有质量(仅影响数据变更的指令,例如set,select)

数据来源:当master接收到著客户端的指令时,除了将指令执行,会将该指令存储到缓冲区中

偏移量

概念:一个数字,描述复制缓冲区中的指令字节的位置

分类

master复制偏移量:记录发给所有slave的指令字节对应位置(多个)

slave复制偏移量:记录slave接受master发送过来的指令字节对应的位置(一个)

数据来源

master:发送一次记录一次

slave:接受一次记录一次

作用:同步信息,对比master与slave的差异,当slave断线后,回复数据使用

心跳机制

进入命令传播阶段的时候,master与slave间需要进行信息交换,使用心跳机制进行维护,实现双方保持在线

master心跳

指令:ping

周期:有repl-ping-slave-period决定,默认是10秒

作用:判断slave是否在线

查询info replication 获取最后一次连接时间间隔,lag项维持在0或1视为正常

slave心跳任务

指令replconfack{offset}

周期:1秒

作用:汇报slave自己的复制偏移量,获取最新的数据变更指令

作用2:判断master是否在线

注意事项

当slave多数掉线,或延迟过高时,master为保证数据稳定性,将拒绝所有信息同步操作

min-slaves-to-write 2
min-slaves-max-lag 8

slave数量少于2个,或者所有slave的延迟都大于10秒时,强制关闭master写功能,停止同步数据

slave数量由slave发送replconf ack确认

slave延迟由发送replconf ack命令确认

Last modification:November 17, 2023
如果觉得我的文章对你有用,请随意赞赏