Redis 入门到分布式（六）常见的持久化开发运维问题

清疚 2023-06-15 07:21 38阅读 0赞

## 个人博客网：[https://wushaopei.github.io/][https_wushaopei.github.io]    (你想要这里多有) ##

## 一、常见问题目录 ##

1.  fork操作
2.  进程外开销
3.  AOF追加阻塞
4.  单机多实例部署

## 二、 fork ##

### 1、Fork操作 ###

1.**同步操作：**Fork操作只是做内存页的拷贝，而不是做整个内存的拷贝，所以说，大部分情况下速度是非常快的，但是如果本身的fork操作比较慢，或者是卡在了某个地方，那么它就会阻塞redis的主线程。

2. **与内存量息息相关：**内存越大，耗时越长（与机器类型有关）

3. **Info:latest\_fork\_usec**

该参数用来查上一次持久化的执行时间，用来辅助对持久化文件内存相关信息进行监控

### 2、改善fork ###

1.  优先使用物理机或者高效支持fork操作的虚拟化技术
2.  控制Redis实例最大可用内存：maxmemory
3.  合理配置Linux内存分配策略：vm.overcommit\_memory=1
4.  降低fork频率：例如放宽AOF重写自动触发时机，不必要的全量复制

## 三、子进程开销和优化 ##

### 1、CPU： ###

> 开销： RDB和AOF文件生成，属于CPU密集型

开销主要体现在对文件的重写，也就是对硬盘的写操作；同时，它本身也是一个CPU密集型的操作；子进程的开销一般可达到90%以上。

> 优化：不做CPU绑定，不和CPU密集型部署

这样可以保证不会产生CPU密集型的竞争。

### 2、内存： ###

>   开销： fork 内存开销，copy-on-write.

fork内存开销，基本上大部分集中于客户端有写入操作创建子线程进行刷数据到硬盘的时候。

>  优化：echo never > /sys/kernel/mm/transparent\_hugepage/enabled

**优化**：不允许单机作部署时发生大量的重写，这样内存的消耗比较小

### 3、硬盘 ###

>  开销： AOF和RDB 文件写入，可以结合iostat,iotop分析

**硬盘优化：**

1） 不要和高硬盘负载服务部署一起 ： 存储服务、消息队列等

2） no-appendfsync-on-rewrite = yes

3) 根据写入量决定磁盘类型：例如ssd

4）单机多实例持久化文件目录可以考虑分盘

## 四、AOF阻塞 ##

### 1、AOF追加阻塞 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70][]

如果我们使用AOF进行持久化，那么，一般会使用呢每秒刷盘的策略。

**分析：**

> 主线程将数据加载到缓冲区，同时它还有一个AOF同步线程，去负责每秒同步刷盘操作，
> 
> 主线程还会负责一项工作，主线程会对比上次AOF同步的时间，如果上次同步时间在两秒之内，主线程就会返回；如果距离上次同步时间超过了两秒，主线程会阻塞，直到同步完成。

实际上，这也是为了达到保证AOF同步安全的一种策略，所以为了达到这一目的，它会一直阻塞直到达到同步完成。

**但是，这里会产生两个问题：**

1）主线程是不能阻塞的

因为主线程要负责日常命令的处理，是非常宝贵的资源，

2）每秒刷盘的策略可能不只会丢失一秒，而是可能会丢失两秒的数据

### 2、**AOF阻塞定位** ###

**1）定位方法1：**

**查看redis日志：**

** ** ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 1][]

在redis日志中，有这么一段，它会告诉你，你的异步AOF同步可能花了太长时间了，你的磁盘是不是有问题，而且这个过程有可能拖慢你的redis。

**2）定位方法2：**

通过命令查看：

info Persistence

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 2][]

[https_wushaopei.github.io]: https://wushaopei.github.io/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191121125442862.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191121125654158.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20191121125948983.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA==,size_16,color_FFFFFF,t_70