前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >redis持久化

redis持久化

作者头像
chenchenchen
发布2023-01-30 17:05:21
4360
发布2023-01-30 17:05:21
举报
文章被收录于专栏:chenchenchen

RDB 优势:

 1.数据库只包含一个文件,通过文件备份策略,定期配置,恢复系统灾难

 2.压缩文件转移到其他介质上 

3.性能最大化,redis开始持久化时,分叉出进程,由子进程完成持久化的工作 ,避免服务器进程执行I/O操作,启动效率高

劣势:如果宕机,数据损失比较大,因为它是没一个时间段进行持久化操作的。也就是积攒的数据比较多,一旦懵逼,就彻底懵逼了

--------------------------------------------------------------------

AOF优势:

1.带来更高的数据安全性。有三种同步策略。每秒同步、每修改同步、不同步。 2.AOF 文件是一个只进行追加操作的日志文件,因此在写入过程中即使出现宕机现象也不影响之前已经存在的内容。 3.如果日志过大,redis可以启动重写机制。在重写过程中产生的对数据库操作记录会保存在一个新文件中,等到重写完成后再追加到现有的文件中。 4.AOF 文件有序地保存了对数据库执行的所有写入操作

劣势:1.对于相同数量的数据集而言,文件比rdb方式要大。 2.效率比rdb低

持久化套路

一般我们在生产上采用的持久化策略为

  • (1)master关闭持久化
  • (2)slave开RDB即可,必要的时候AOF和RDB都开启

该策略能够适应绝大部分场景,绝大部分集群架构。 为什么是绝大部分场景? 因为这套策略存在部分的数据丢失可能性。redis的主从复制是异步的,master执行完客户端请求的命令后会立即返回结果给客户端,然后异步的方式把命令同步给slave。因此master可能还未来得及将命令传输给slave,就宕机了,此时slave变为master,数据就丢了。 幸运的是,绝大部分业务场景,都能容忍数据的部分丢失。假设,真的遇到缓存雪崩的情况,代码中也有熔断器来进行资源保护,不至于所有的请求都转发到数据库上,导致我们的服务崩溃! ps:这里的缓存雪崩是指同一时间来了一堆请求,请求的key在redis中不存在,导致请求全部转发到数据库上。 为什么是绝大部分集群架构? 因为在集群中存在redis读写分离的情况,就不适合这套方案了。 幸运的是,由于采用redis读写分离架构,就必须要考虑主从同步的延迟性问题,徒增系统复杂度。目前业内采用redis读写分离架构的项目,真的太少了。

为什么这么做

(1)master关闭持久化

原因很简单,因为无论哪种持久化方式都会影响redis的性能,哪一种持久化都会造成CPU卡顿,影响对客户端请求的处理。为了保证读写最佳性能,将master的持久化关闭! RDB持久化 RDB持久化是将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化),保存的文件后缀是rdb;当Redis重新启动时,可以读取快照文件恢复数据。 那么RDB持久化的过程,相当于在执行bgsave命令。该命令执行过程如下图所示

如图所示,主线程需要调用系统函数fork(),构建出一个子进程进行持久化!很不幸的是,在构建子进程的过程中,父进程就会阻塞,无法响应客户端的请求! 而且,在测试中发现,fork函数在虚拟机上较慢,真机上较快。考虑到现在都是部署在docker容器中,很少部署在真机上,为了性能,master不建议打开RDB持久化! AOF持久化 RDB持久化是将进程数据写入文件,而AOF持久化(即Append Only File持久化),则是将Redis执行的每次写命令记录到单独的日志文件中。 随着时间的流逝,你会发现这个AOF文件越来越大,于是redis有一套rewrite机制,来缩小AOF文件的体积。然而,在rewrite的过程中也是需要父进程来fork出一个子进程进行rewrite操作。至于fork函数的影响,上面提到过了。 还有一个就是刷盘策略fsync,这个值推荐是配everysec,也就是Redis会默认每隔一秒进行一次fsync调用,将缓冲区中的数据写到磁盘。 然而,如果磁盘性能不稳定,fsync的调用时间超过1秒钟。此时主线程进行AOF的时候会对比上次fsync成功的时间;如果距上次不到2s,主线程直接返回;如果超过2s,则主线程阻塞直到fsync同步完成。 因此AOF也是会影响redis的性能的。

ps:linux函数中,wrtie函数将数据写入文件的时候,是将数据写入操作系统的缓冲区,还并未刷入磁盘。而fsync函数,可以强制让操作系统将缓冲区数据刷入磁盘。

综上所述,我们为了保证读写性能最大化,将master的持久化关闭。

(2)slave开RDB即可,必要的时候AOF和RDB都开启

首先,我先说明一下,我不推荐单开AOF的原因是,基于AOF的数据恢复太慢。 你要想,我们已经做了主从复制,数据已经实现备份,为什么slave还需要开持久化? 因为某一天可能因为某某工程,把机房的电线挖断了,就会导致master和slave机器同时宕机。 那么这个时候,我们需要迅速恢复集群,而RDB文件文件小、恢复快,因此灾难恢复常用RDB文件。

其次,官网也不推荐单开AOF,地址如下: https://redis.io/topics/persistence 截图如下

所以,如果实在对数据安全有一定要求,将AOF和RDB持久化都开启。

另外,做好灾难备份。利用linux的scp命令,定期将rdb文件拷贝到云服务器上。 ps:scp是secure copy的简写,用于在Linux下进行远程拷贝文件的命令,和它类似的命令有cp,不过cp只是在本机进行拷贝不能跨服务器,而且scp传输是加密的。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2019-03-27,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • RDB 优势:
  • AOF优势:
  • 持久化套路
    • 为什么这么做
    相关产品与服务
    数据库
    云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档