[转帖]美团在Redis上踩过的一些坑-2.bgrewriteaof问题

美团在Redis上踩过的一些坑-2.bgrewriteaof问题

博客分类：

• redis
• 运维

aofaof rewrite 

转载请注明出处哈:http://carlosfu.iteye.com/blog/2254154

---

 

一、背景

1. AOF:

Redis的AOF机制有点类似于Mysql binlog，是Redis的提供的一种持久化方式（另一种是RDB），它会将所有的写命令按照一定频率(no, always, every seconds)写入到日志文件中，当Redis停机重启后恢复数据库。

2. AOF重写：

(1) 随着AOF文件越来越大，里面会有大部分是重复命令或者可以合并的命令（100次incr = set key 100）

(2) 重写的好处：减少AOF日志尺寸，减少内存占用，加快数据库恢复时间。

二、单机多实例可能存在Swap和OOM的隐患:

由于Redis的单线程模型，理论上每个redis实例只会用到一个CPU, 也就是说可以在一台多核的服务器上部署多个实例（实际就是这么做的）。但是Redis的AOF重写是通过fork出一个Redis进程来实现的，所以有经验的Redis开发和运维人员会告诉你，在一台服务器上要预留一半的内存（防止出现AOF重写集中发生，出现swap和OOM）。

三、最佳实践

1. meta信息：作为一个redis云系统，需要记录各个维度的数据，比如：业务组、机器、实例、应用、负责人多个维度的数据，相信每个Redis的运维人员都应该有这样的持久化数据(例如Mysql)，一般来说还有一些运维界面，为自动化和运维提供依据

例如如下：

2. AOF的管理方式：

(1) 自动：让每个redis决定是否做AOF重写操作（根据auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个参数）：

(2) crontab: 定时任务，可能仍然会出现多个redis实例，属于一种折中方案。

(3) remote集中式：

最终目标是一台机器一个时刻，只有一个redis实例进行AOF重写。

具体做法其实很简单，以机器为单位，轮询每个机器的实例，如果满足条件就运行(比如currentSize和baseSize满足什么关系)bgrewriteaof命令。

期间可以监控发生时间、耗时、频率、尺寸的前后变化

策略	优点	缺点
自动	无需开发	1. 有可能出现(无法预知)上面提到的Swap和OOM 2. 出了问题，处理起来其实更费时间。
AOF控制中心（remote集中式）	1. 防止上面提到Swap和OOM。 2. 能够收集更多的数据（aof重写的发生时间、耗时、频率、尺寸的前后变化），更加有利于运维和定位问题（是否有些机器的实例需要拆分）。	控制中心需要开发。

一台机器轮询执行bgRewriteAof代码示例：

附图一张：