Redis笔记(四)

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
日志服务 SLS,月写入数据量 50GB 1个月
简介: Redis笔记

流程


网络异常,图片无法展示
|

dump.rdb也就是备份文件,redis可以根据这个文件来恢复数据。


备份配置


redis.conf可以对rdb文件进行配置


  • dbfilename dump.rdb   文件名配置
  • dir  ./ 文件位置配置,默认为Redis启动时命令行所在的目录下
  • stop-writes-on-bgsave-error  yes  当Redis无法写入磁盘的话,直接关掉Redis的写操作。yes打开
  • rdbcompression  yes 对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能。推荐yes.
  • rdbchecksum  yes 在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能,推荐yes.


最重要的命令 save

网络异常,图片无法展示
|


  • save 900 1 # 3600秒(60分钟)内有1个key写入就保存(备份)
  • save 300 10 # 300秒(5分钟)内有10个key写入就保存(备份)
  • save 60 10000 # 60秒(1分钟)内有10000个key写入就保存(备份)可以同时打开多个。


而上面的数据问题也就是因为这个原因,比如 sava  20 10 在20秒内有10个key写入就保存,但当在18秒时宕机了,这时就会导致数据丢失。问题虽然有解决,但没完全解决。


rdb文件的使用


先通过config get dir  查询rdb文件的目录
将*.rdb的文件拷贝到别的地方
rdb的恢复


  • 关闭Redis
  • 先把备份的文件拷贝到工作目录下cp dump2.rdb dump.rdb
  • 启动Redis, 备份数据会直接加载


优点:


适合大规模数据恢复节省空间对数据完整性和一致性要求不高恢复速度快


缺点:


在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑,数据量大的时候,耗性能


AOF


以日志的形式来记录每个操作(增量保存),将redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。


配置


  • aof默认不开启。
  • 在redis.confg中配置文件名称,默认为appendonly.aofaof文件的保存路径,同rdb的路径一致
  • 两种持久化同时开启,系统默认取aof的数据(数据不会存在丢失)
  • aof的备份机制和性能虽然和rdb不同,但备份和操作同rdb一样
  • 正常启动
  • 修改默认的appendonly no,改为yes
  • 将有数据的aof文件复制一份保存到对应目录(查看目录:config get dir)
  • 恢复:重启redis然后重新加载


  • 异常恢复
  • 修改默认的appendonly no,改为yes
  • 如遇到aof文件损坏,通过/usr/local/bin/redis-check-aof --fix appendonly.aof进行恢复
  • 备份被写坏的aof文件
  • 恢复:重启redis,然后重新加载


AOF同步频率(备份频率)设置


  • appendfsync always始终同步,每次redis的写入都会立刻记入日志;性能较差但数据完整性比较好
  • appendfsync everysec每秒同步,每秒计入日志一次,如果宕机,本秒的数据可能丢失
  • appendfsync noredis不主动进行同步,把同步时机交给操作系统。


rewrite 压缩(重写)


AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制, 当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩, 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof (bg  rewrite  aof)


重写原理,如何实现重写


AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename,这里不懂看下面的流程),redis4.0版本后的重写,是指上就是把rdb 的快照,以二级制的形式附在新的aof头部,作为已有的历史数据,替换掉原来的流水账操作。也就是简写,栗如:set v1 v2  set  b1 b2 会变成set v1 v2 b1  b2。


配置no-appendfsync-on-rewrite:如果no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存,用户请求不会阻塞,但是在这段时间如果宕机会丢失这段时间的缓存数据。(降低数据安全性,提高性能)
如果no-appendfsync-on-rewrite=no,  还是会把数据往磁盘里刷,但是遇到重写操作,可能会发生阻塞。(数据安全,但是性能降低)


触发机制,何时重写


Redis会记录上次重写时的AOF大小,默认配置(可配置)是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发(重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定Redis要满足一定条件才会进行重写。)


文件大小触发重写配置auto-aof-rewrite-percentage:设置重写的基准值,文件达到100%时开始重写(文件是原来重写后文件的2倍时触发)
auto-aof-rewrite-min-size:设置重写的基准值,最小文件64MB。达到这个值开始重写。
例如:文件达到70MB开始重写,降到50MB,下次什么时候开始重写?100MB
系统载入时或者上次重写完毕时,Redis会记录此时AOF大小,设为base_size,
如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下,Redis会对AOF进行重写。


重写流程


(1)bgrewriteaof触发重写,先判断是否当前有bgsave或bgrewriteaof在运行,如果有,则等待该命令结束后再继续执行。
(2)主进程fork出子进程执行重写操作,保证主进程不会阻塞。
(3)子进程遍历redis内存中数据到临时文件,客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
(4)1).子进程写完新的AOF文件后,向主进程发信号,父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
(5)使用新的AOF文件覆盖旧的AOF文件,完成AOF重写。

网络异常,图片无法展示
|


优势


  • 备份机制更稳健,丢失数据概率更低
  • 可读的日志文件,通过操作aof稳健,可以处理误操作


劣势


  • 比起rdb占用更多的磁盘空间
  • 恢复备份速度更慢
  • 每次读写都同步的话,有一定性能压力
  • 存在一定bug,造成恢复不能


总结


用哪个好


官方推荐两个都启用。
如果对数据不敏感,可以选单独用RDB。
不建议单独用AOF,因为可能会出现Bug。
如果只是做纯内存缓存,可以都不用。


官方建议(没事的可以晃俩眼)


  • RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
  • AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
  • Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
  • 只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
  • 同时开启两种持久化方式
  • 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
  • RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?
  • 建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),快速重启,而且不会有AOF可能潜在的bug,留着作为一个万一的手段。


性能建议


因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则。
如果使用AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。
代价,一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值。


Redis的主从复制


是什么,能干嘛

主机数据更新后根据配置和策略,自动同步到备机的master(主)/slaver(从)机制,Master以写为主,Slave以读为主

  • 读写分离,性能扩展
  • 容灾快速恢复 (也就是解决宕机问题,一个slaver(从)死了可以用其他的slaver(从),而主死了后面说。)

网络异常,图片无法展示
|

操作

操作之前有几个配置注意下

  1. 开启daemonize yes  (后台启动)
  2. dump.rdb名字dbfilename  (之前有修改过的注意一下)
  3. appendonly  AOP的生成  关掉或者换名字

新建多个config文件,并拷贝redis.conf里的内容,include命令去拷贝。

网络异常,图片无法展示
|

编辑新建的redis6379.conf,:wq!保存退出

网络异常,图片无法展示
|

一样的操作新建编辑redis6380.conf和redis6381.conf,注意里面的名字和端口不一样

  • Pid文件名字pidfile
  • 指定端口port
  • slave-priority 10 设置从机的优先级,值越小,优先级越高,用于选举主机时使用。默认100
  • Log文件名字

启动三台redis服务器

网络异常,图片无法展示
|

看查系统进程,三台服务器是否启动

网络异常,图片无法展示
|

看查三台主机运行情况,role属性角色

网络异常,图片无法展示
|

配置主从

命令:slaveof   成为某个实例的从服务器
1、在6380和6381上执行 : slaveof 127.0.0.1 6379

2、在主机上写,在从机上可以读取数据
在从机上写数据报错

3、主机挂掉,重启就行,一切如初
4、从机重启需重设:slaveof 127.0.0.1 6379
可以将配置增加到文件中。永久生效。

几个常见的问题

问:切入点问题?slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来,那之前的k1,k2,k3是否也可以复制?
答:当slave1挂掉之后,再次连接,他会去和主master同步数据,从头复制数据。
问:从机是否可以写?set可否?
答:从机只负责读取,主机负责写入。
问:主机shutdown后情况如何?从机是上位还是原地待命?
答:一般情况下当主机挂掉之后,从机是会原地待命的,不会上位(要上位的话,怎么上,这也就是下面要讲的哨兵机制)
问:主机又回来了后,主机新增记录,从机还能否顺利复制?
其中一台从机down后情况如何?依照原有它能跟上大部队吗?
答:主机回来后新增的数据记录,会同步到从机,从机联机主机时都会去比较数据然后同步。

复制原理

  • Slave启动成功连接到master后会发送一个sync命令
  • Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令, 在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步
  • 全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
  • 增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步
  • 但是只要是重新连接master,一次完全同步(全量复制)将被自动执行
    网络异常,图片无法展示
    |

性质

  • 一主俩从,一般情况下都是配置的一主俩从。
  • 薪火相传
  • 上一个Slave可以是下一个slave的Master,Slave同样可以接收其他slaves的连接和同步请求,那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。


用slaveof  
中途变更转向:会清除之前的数据,重新建立拷贝最新的
风险是一旦某个slave宕机,后面的slave都没法备份
主机挂了,从机还是从机,无法写数据了

网络异常,图片无法展示
|

  • 反客为主
  • 当一个master宕机后,后面的slave可以立刻升为master,其后面的slave不用做任何修改。


用slaveof  no one  将从机变为主机。


哨兵模式(sentinel)


反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库

网络异常,图片无法展示
|

怎么玩(使用步骤)

调整为一主二仆模式,6379带着6380、6381

自定义的/myredis目录下新建sentinel.conf文件,名字绝不能错

配置哨兵,填写内容

sentinel monitor mymaster 127.0.0.1 6379 1
其中mymaster为监控对象起的服务器名称, 1 为至少有多少个哨兵同意迁移的数量。
启动哨兵

/usr/local/bin
redis做压测可以用自带的redis-benchmark工具
执行redis-sentinel /myredis/sentinel.conf

当主机挂掉,从机选举中产生新的主机

(大概10秒左右可以看到哨兵窗口日志,切换了新的主机)
哪个从机会被选举为主机呢?根据优先级别:replica-priority
原主机重启后会变为从机。

小缺点:复制延时

由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。(也就是RBD和AOF导致的)

流程

优先级在redis.conf中默认:replica-priority 100,值越小优先级越高
偏移量是指获得原主机数据最全的
每个redis实例启动后都会随机生成一个40位的runid

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
打赏
0
0
2
0
333
分享
相关文章
|
9月前
|
【Redis系列笔记】双写一致性
本文讨论了缓存不一致问题及其后果,如价格显示错误和订单计算错误。问题主要源于并发和双写操作的异常。解决方案包括使用分布式锁(但可能导致性能下降和复杂性增加)、延迟双删策略(通过延迟删除缓存来等待数据同步)以及异步同步方法,如通过Canal和MQ实现数据的最终一致性。面试中,可以提及这些策略来确保数据库和缓存数据的一致性。
717 1
【Redis系列笔记】双写一致性
|
9月前
|
【Redis系列笔记】缓存三剑客
缓存穿透是指请求一个不存在的数据,缓存层和数据库层都没有这个数据,这种请求会穿透缓存直接到数据库进行查询。它通常发生在一些恶意用户可能故意发起不存在的请求,试图让系统陷入这种情况,以耗尽数据库连接资源或者造成性能问题。 缓存击穿发生在访问热点数据,大量请求访问同一个热点数据,当热点数据失效后同时去请求数据库,瞬间耗尽数据库资源,导致数据库无法使用。 缓存雪崩是缓存中大量key失效后当高并发到来时导致大量请求到数据库,瞬间耗尽数据库资源,导致数据库无法使用。
205 2
蚂蚁金服P7私藏的Redis原理与实践内部笔记
Redis 是完全开源免费的,是一个高性能的key-value类型的内存数据库。整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过 10万次读写操作,是已知性能最快的Key-Value DB。
127 1
Redis原理之网络通信协议笔记
1. RESP协议 ​2. 自定义Socket连接Redis
Redis原理之网络模型笔记
Redis采用单线程模型,这意味着一个Redis服务器在任何时刻都只会处理一个请求。Redis的网络模型涉及到阻塞I/O(Blocking I/O)、非阻塞I/O(Non-blocking I/O)、I/O多路复用(I/O Multiplexing)、信号驱动I/O(Signal-driven I/O)以及异步I/O(Asynchronous I/O)。
123 1
【Redis系列笔记】分布式锁
分布式锁:满足分布式系统或集群模式下多进程可见并且互斥的锁。 分布式锁的核心思想就是让大家都使用同一把锁,只要大家使用的是同一把锁,那么我们就能锁住线程,不让线程进行,让程序串行执行,这就是分布式锁的核心思路
769 2
Redis - 笔记
Redis是开源的内存数据结构存储系统,兼备数据库、缓存和消息中间件功能。它支持字符串、哈希、列表、集合、有序集合等数据结构,以及地理空间、基数统计和位图等特殊类型。Redis具备复制、LUA脚本、LRU事件、事务、持久化、哨兵和集群等高级特性,以实现高可用性。应用场景包括计数器、存储用户信息、消息队列、共同关注等。字符串最大容量为512M。
Redis系列学习文章分享---第八篇(Redis快速入门之达人探店--发布探店笔记 + 查看探店笔记 + 点赞功能 + 点赞排行榜)
Redis系列学习文章分享---第八篇(Redis快速入门之达人探店--发布探店笔记 + 查看探店笔记 + 点赞功能 + 点赞排行榜)
54 0
【Redis系列笔记】Redis集群
集群是一种在多个计算机或服务器之间分配和管理任务的方式。它们被广泛应用于大型计算任务、数据处理、网络服务和高性能计算等领域。在Redis中,主要有以下三种集群,分别是主从集群,哨兵集群,分片集群。
235 18
|
9月前
|
【Redis系列笔记】Redis入门
本文介绍了Redis常用命令,以及SpringBoot集成Spring Data Redis和Spring Cache。Spring Data Redis 提供了对 Redis 的操作方法,而 Spring Cache 则提供了基于注解的缓存功能,可以方便地将方法的返回值缓存到 Redis 中,以提高性能和减少对数据源的访问次数。这样的集成可以帮助开发者更便捷地利用 Redis 来管理应用程序的数据和缓存。
192 4
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等