|
|
51CTO旗下网站
|
|
移动端

面试中经常被问到的Redis持久化与恢复,该如何解决?

本文主要讲了 Redis 的持久化相关功能,持久化一直是影响 Redis 性能的高发地,也是面试中经常被问到的。

作者:程序猿的内心独白来源:申博太阳城|2019-02-21 10:49

一、前言

本文主要讲了 Redis 的持久化相关功能,持久化一直是影响 Redis 性能的高发地,也是面试中经常被问到的。

包括 RDB 相关的特定和优缺点,AOF 的优缺点,事实上,由于 RDB 的数据实时性问题,目前用 AOF 比较多了,而持久化恢复也是优先 AOF。

RDB 是旧的模式,现在基本上都使用 AOF,当然,今天两个都会一起聊聊。

二、 RDB

RDB 流程图:

RDB 特点:

1、RDB 是一种快照模式,即——保存的是 key value 数据内容。

2、RDB 有 2 种持久方式,同步 save 模式和异步 bgsave 模式。由于 save 是同步的,所以可以保证数据一致性,而 bgsave 则不能。

3、save 可以在客户端显式触发,也可以在 shutdown 时自动触发;bgsave 可以在客户端显式触发,也可以通过配置由定时任务触发,也可以在 slave 节点触发。

4、save 导致 redis 同步阻塞,基本已经废弃。bgsave 则不会导致阻塞,但也有缺点:在 fork 时,需要增加内存服务器开销,因为当内存不够时,将使用虚拟内存,导致阻塞 Redis 运行。所以,需要保证空闲内存足够。

5、默认执行 shutdown 时,如果没有开启 AOF,则自动执行 bgsave。

6、每次的 RDB 文件都是替换的。

关于优化:

Redis 会压缩 RDB 文件,使用 LZF 算法,让最终的 RDB 文件远小于内存大小,默认开启。但会消耗 CPU。

RDB 缺点:

1、无法秒级持久化。

2、老版本 Redis 无法兼容新版本 RDB。

RDB 优点:

1、文件紧凑,适合备份,全量复制场景。例如每 6 小时执行 bgsave,保存到文件系统之类的。

2、Redis 加载 RDB 恢复数据远远快于 AOF。

三、 AOF

由于 RDB 的数据实时性问题,AOF(append only file) 是目前 Redis 持久化的主流方式。

AOF 特点:

1、默认文件名是 appendonly.aof。和 RDB 一样,保存在配置中 dir 目录下。

2、AOF 相比较于 RDB,每次都会保存写命令,数据实时性更高。

3、AOF 由于每次都会记录写命令,文件会很大,因此需要进行优化,称之为“重写机制”(下面详细说)。

4、AOF 每次保存的写命令都放在一个缓冲区,根据不同的策略(下面详细说)同步到磁盘。

“重写机制” 细节:

1、fork 子进程(类似 bgsave)

2、主进程会写到2个缓冲区,一个是原有的 “AOF 缓存区”,一个是专门为子进程准备的 “AOF 重写缓冲区”;

3、子进程写到到新的 AOF 文件中,批量的,默认 32m;写完后通知主进程。

4、主进程把“AOF 重写缓冲区”的数据写到新 AOF 文件中。

5、将新的 AOF 文件替换老文件。

重写流程图:

缓冲区同步策略,由参数 appendfsync 控制,一共3种:

1、always:调用系统 fsync 函数,直到同步到硬盘返回; 严重影响redis性能。

2、everysec:先调用 OS write 函数, 写到缓冲区,然后 redis 每秒执行一次 OS fsync 函数。 推荐使用这种方式。

3、no: 只执行 write OS 函数,具体同步硬盘策略由 OS 决定; 不推荐,数据不安全,容易丢失数据。

四、持久化恢复

AOF 和 RDB 文件都可以用于服务器重启时的数据恢复,具体流程如下图:

从图中可以看出优先加载 AOF,当没有 AOF 时才加载 RDB。当 AOF 或者 RDB 存在错误,则加载失败。

五、问题排查和性能优化

Redis 持久化是影响 Redis 性能的高发地,也是面试中常问的问题。

1. fork 操作

当 Redis 做 RDB 或者 AOF 重写时,必然要进行 fork 操作,对于 OS 来说,fork 都是一个重量级操作。而且,fork 还会拷贝一些数据,虽然不会拷贝主进程所有的物理空间,但会复制主进程的空间内存页表。对于 10GB 的 Redis 进程,需要复制大约 20MB 的内存页表,因此 fork 操作耗时跟进程总内存量息息相关,再加上,如果使用虚拟化技术,例如 Xen 虚拟机,fork 会更加耗时。

一个正常的 fork 耗时大概在 20毫秒左右。为什么呢,假设一个 Redis 实例的 OPS 在 5 万以上,如果 fork 操作耗时在秒级,那么僵拖慢几万条命令的执行,对生产环境影响明显。

我们可以在 Info stats 统计中查询 latestforkusec 指标获取最近一次 fork 操作耗时,单位微秒。

如何优化:

1、优先使用物理机或者高效支持 fork 的虚拟化技术,避免使用 Xen。

2、控制 redis 实例***内存,尽量控制在 10GB 以内。

3、合理配置 Linux 内存分配策略,避免内存不足导致 fork 失败。

4、降低 fork 的频率,如适度放宽 AOF 自动触发时机,避免不必要的全量复制。

2. 子进程开销

fork 完毕之后,会创建子进程,子进程负责 RDB 或者 AOF 重写,这部分过程主要涉及到 CPU,内存,硬盘三个地方的优化。

1、CPU 写入文件的过程是 CPU 密集的过程,通常子进程对单核 CPU 利用率接近 90%。 如何优化呢?既然是 CPU 密集型操作,就不要绑定单核 CPU,因为这样会和父 CPU 进行竞争。同时,不要和其他 CPU 密集型服务不是在一个机器上。如果部署了多个 Redis 实例,尽力保证统一时刻只有一个子进程执行重写工作。

2、内存 子进程通过 fork 操作产生,占用内存大小等同于父进程,理论上需要两倍的内存完成持久化操作,但 Linux 有 copy on write 机制,父子进程会共享相同的物理内存页,当父进程处理写操作时,会把要修改的页创建对应的副本,而子进程在 fork 操作过程中,共享整个父进程内存快照。 即——如果重写过程中存在内存修改操作,父进程负责创建所修改内存页的副本。这里就是内存消耗的地方。 如何优化呢?尽量保证同一时刻只有一个子进程在工作;避免大量写入时做重写操作。

3、硬盘 硬盘开销分析:子进程主要职责是将 RDB 或者 AOF 文件写入硬盘进行持久化,势必对硬盘造成压力,可通过工具例如 iostat,iotop 等,分析硬盘负载情况。

如何优化:

1、不要和其他高硬盘负载的服务放在一台机器上,例如 MQ,存储。

2、AOF 重写时会消耗大量硬盘 IO,可以开启配置 no-appendfsync-on-rewrite,默认关闭。表示在 AOF 重写期间不做 fsync 操作。

3、当开启 AOF 的 Redis 在高并发场景下,如果使用普通机械硬盘,每秒的写速率是 100MB左右,这时,Redis 的性能瓶颈在硬盘上,建议使用 SSD。

4、对于单机配置多个 Redis 实例的情况,可以配置不同实例分盘存储 AOF 文件,分摊硬盘压力。

3. AOF 追加阻塞

当开启 AOF 持久化时,常用的同步硬盘的策略是“每秒同步” everysec,用于平衡性能和数据安全性,对于这种方式,redis 使用另一条线程每秒执行 fsync 同步硬盘,当系统资源繁忙时,将造成 Redis 主线程阻塞。

流程图如下:

通过上图可以发现:everysec 配置最多可能丢失 2 秒数据,不是 1 秒;如果系统 fsync 缓慢,将会导致 Redis 主线程阻塞影响效率。

问题定位:

1、发生 AOF 阻塞时,会输入日志。用于记录 AOF fsync 阻塞导致拖慢 Redis 服务的行为。

2、每当 AOF 追加阻塞事件发生时,在 info Persistence 统计中,aofdelayedfsync 指标会累加,查看这个指标方便定位 AOF 阻塞问题。

3、AOF 同步最多运行 2 秒的延迟,当延迟发生时说明硬盘存在性能问题,可通过监控工具 iotop 查看,定位消耗 IO 的进程。

4. 单机多实例部署

Redis 单线程架构无法充分利用多核CPU,通常的做法是一台机器上部署多个实例,当多个实例开启 AOF 后,彼此之间就会产生CPU 和 IO 的竞争。

如何解决这个问题呢?

让所有实例的 AOF 串行执行。

我们通过 info Persistence 中关于 AOF 的信息写出 Shell 脚本,然后串行执行实例的 AOF 持久化。

整个过程如图:

通过不断判断 AOF 的状态,手动执行 AOF 重写,保证 AOF 不会存在竞争。具体的 Shell 编写以及 info 信息判断,可以查看下图:

六、总结

本文主要讲了 Redis 的持久化相关功能,持久化一直是影响 Redis 性能的高发地,也是面试中经常被问到的。包括 RDB 相关的特定和优缺点,AOF 的优缺点,事实上,由于 RDB 的数据实时性问题,目前用 AOF 比较多了。而持久化恢复也是优先 AOF。

关于持久化的问题排查,就很麻烦了,但无非几个方面,fork 耗时,子进程的 CPU,内存,硬盘开销,AOF 的同步阻塞,单机多实例部署。

这些优化,可以通过前面写的分析进行排查。

【编辑推荐】

  1. Kubernetes持久化存储是个难题,解决方案有哪些?
  2. 关于“灾难恢复即服务”选型的十个提示
  3. 为什么不搞集群服务也能实现Redis高可用?
  4. 分布式缓存Redis扫盲教程
  5. Redis数据分片方案实践
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

16招轻松掌握PPT技巧

16招轻松掌握PPT技巧

GET职场加薪技能
共16章 | 晒书包

289人订阅学习

20个局域网建设改造案例

20个局域网建设改造案例

网络搭建技巧
共20章 | 捷哥CCIE

645人订阅学习

WOT2019全球人工智能技术峰会

WOT2019全球人工智能技术峰会

通用技术、应用领域、企业赋能三大章节,13大技术专场,60+国内外一线人工智能精英大咖站台,分享人工智能的平台工具、算法模型、语音视觉等技术主题,助力人工智能落地。
共50章 | WOT峰会

0人订阅学习

读 书 +更多

网管第一课——网络组建与管理

本书针对初级网管朋友所需掌握的网络组建和网络管理技能,以示例方式编写而成,其主要特点就是实用性和可操作性非常强。 全书共分8章,分...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO播客

申博太阳城
网站地图 申博登录网址 申博游戏下载 澳门星际赌场 真人百家乐
菲律宾申博在线登入网站 菲律宾太阳申博申请提款 菲律宾申博怎么充值 申博在线138管理
申博官方网址 菲律宾太城申博 申博登入网址 百家乐登入网址
申博太阳城登入 申博游戏注册 盛618登入 申博官网登录
申博游戏手机下载 申博登录不了 老虎机游戏 申博娱乐官网