福泉市建设局网站,网站开发与运营方向和企业管理方向,设计本官方网站 网络服务,网站再就业技能培训班redis的数据类型的操作增删改查
redis的高可用#xff1a;
在集群当中有一个非常重要的指标#xff0c;提供正常服务的时间的百分比#xff08;365天#xff09;99.9%
redis的高可用的含义要更加宽泛#xff0c;正常服务是指标之一数据容量扩展#xff0c;数据的安全性…redis的数据类型的操作增删改查
redis的高可用
在集群当中有一个非常重要的指标提供正常服务的时间的百分比365天99.9%
redis的高可用的含义要更加宽泛正常服务是指标之一数据容量扩展数据的安全性
在redis中实现这种高可用技术持久化 主从复制哨兵模式 cluster集群。
持久化: 持久化是最简单的高可用方法主要作用是数据备份也就是把redis缓存在内存中的数据保存到本地的硬盘中
redis持久化的两种方式
1、RDB持久化redis在内存中的数据定时保存到磁盘。自动执行手动执行
2、AOF持久化redis的操作日志以追加的方式写入一个AOF的文件类似于mysql的binlog。 rdb的持久化 指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘快照持久化用二进制压缩存储
保存的文件名的后缀.rdb redis启动时可以直接读取快照文件实现数据恢复。
rdb的触发机制
手动机制:save bgsave都可以省程RDB文件。
save创建RDB文件时整个redis进程会被阻塞期间redis将无法进行读写操作直到RDB文件创建完成为止。
bgsave就是主从复制的机制
bgsave的特点就是父进程会通过fork机制创建一个子进程子进程的创建过程中父进程会阻塞子进程创建完毕主进程会解除阻塞然后由子进程来创建RDB文件。创建完成之后通知主进程更新通知信息。 save 900 1
900秒 当时间到900秒时如果redis的数据至少发生一次变化就会执行bgsave
save 300 10
300 秒 时间到300秒时如果redis的数据至少发生10次变化就会执行bgsave
save 60 10000
60秒 时间到60秒时如果redis的数据至少发生一万次变化就会执行bgsave sava 120 1000 bgsave
save 60 10000 bgsave
数据变动越多执行的时间要越短数据变动不大时间间隔要长一点。 rdbcompression yes
开启rdb的文件压缩功能在高并发场景建议关闭。 除了配置文件中的save m n 之外
主从复制从节点执行全量复制操作主节点会执行bgsave把rdb文件传送给从节点。
关闭主进程shutdown只会会自动执行rdb的持久化 启动时加载
发现rdb文件被损坏日志中会打印错误redis会拒绝启动。
redis-check-rdb修复rdb的持久化文件。 AOF持久化
aof持久化是将redis的每一次读 写 删除命令记录到一个单独的.aof结尾的文件。查询操作由主进程记录。当redis重启时再次执行AOF文件中的命令来恢复数据。
AOF的实时性更好也是主流的持久化方案。 aof-load-truncated yes
用于判断AOF文件如果被截断时的行为
yes发现在被截断写入过程中出现了异常导致文件未能完全写入 redis会尽可能恢复文件中的数据redis会继续运行
no发现AOF文件被截断redis将拒绝启动。
数据完整性要求比较高用no
注重数据服务器的可用性用yes rdb是redis的默认持久化文件但是一但开启AOF持久化那么redis会以AOF的持久化文件作为最高优先级。 AOF的重写功能
1、随着时间增长AOF文件当中的数据也会不断增加,AOF的文件也会也来越大过大的AOF文件不仅仅会影响也会导致数据恢复的时间过长。
文件重写是指定期的重写AOF文件减小AOF文件的体积。AOF重写是把redis进程内的数据转化为写的命令同步到新的aof文件当中不会额外的生成一个新的文件只是在原内容当中进行压缩。不会对原有的AOF文件进行任何读写的操作。 *文件重写虽然是AOF持久化强烈推荐的但不是必须的没有重写并不影响redis启动时读写数据在实际中会关闭自动的文件重写通过定时任务来完成。 AOF同步文件的策略的三种方式
appendfsync always
写入过程中会立刻调用redis系统的fsync 操作立刻写入到AOF文件这次写入都执行同步硬盘的性能有瓶颈硬盘的寿命也会大大降低
appendfsync everysec命令写入调用write操作write操作结束后线程会返回。FSYNC同步文件操作由专门的线程每秒调用一次这是一个这种的策略是性能喝安全性的平衡是redis的默认配置也是推荐配置 appendfsync no 写入操作调用系统的write操作不对AOF文件进行同步操作系统来同步同步周期30秒文件同步的时间不可控缓冲区会堆积大量数据数据的安全也无法保证。 重写的出发条件是什么
1、手动触发
redis-cli bgrewriteaof
2、自动触发
auto-aof-rewrite-percentage 100
文件的大小超过基准的百分比默认值就是100文件的超过两倍时执行bgrewriteaof设置为0禁用自动触发
100M 200M 200M 400M
auto-aof-rewrite-min-size 64mb
文件大于基准值才会进行重写整个值时AOF文件执行重写的最小值避免开始穷redis后文件太小然后频繁的进行重写。 AOF为什么能够压缩文件
1、重写的过程中过期的数据不会写入文件
2、无效的命令不在写入文件数据被重复设置set test1 set test 2 删除的数据也不会写入 多条命令合并成一个 sadd test1 v1 sadd test1 v2
sadd test1 v3 sadd test1 v1 v2 v3
重写之后AOF文件当中的命令减少了空间也少了恢复速度也增增加了 重写不是必须的 RDB和AOF之间的优缺点
RDB的优点:文件体积小如果需要备份网络传输速度很快适合全量复制恢复速度也比AOF要快
缺点做不了实时的持久化数据如此重要不能够容忍丢失的另外RDB需要满足特定的格式兼容性很差老版本的RDB不支持新版本redis的版本一定要一致5.0.7版本
AOF的优点秒级的持久化。兼容性好文本格式保存的命令。
缺点文件大恢复速度慢。AOF持久化需要频繁的向磁盘写入数据磁盘的io压力也很大对redis主进程的性能也会有一定影响。 重点
持久化方式redis的持久化也算是高可用的一种通过备份文件来恢复数据冷备份。
rdb sava线上禁用bgsave
AOF实时持久化写入的是操作的命令除了查 set del 会记录 get select不计入
实时记录恢复方式类似于mysql的binlog
重写推荐但不是必须的重写也是主进程创建一个子进程在过程中产生的数据以及同步策略都会写入到AOF当中。
实验重复写入数据 重复插入同一个数据只会写入最后一个设置的数据
