Redis RDB持久化

redis持久化

redis提供了两种把内存数据持久化到磁盘的方式，RDB快照方式和AOF日志方式。

不论使用那种方式，都无法保证redis数据一点都不丢失。rdb只是redis在某一时刻的数据快照snapshot，数据丢失程度主要取决于距离上次做snapshot的时间间隔，越近的snapshot丢失的数据越少。

AOF（appendonly file）在很多人眼里，是不会丢失数据。然而AOF也存在数据丢失的状况，因为AOF并不是传统RDBMS的WAL日志（Wrtite Ahead Log，或者说是commit log）。aof是redis在命令执行成功之后，才写入到磁盘上日志。如果命令执行成功，而fsync操作没有执行，即数据没有写入到磁盘，那么存在数据丢失。

下面的内容主要讨论RDB快照持久化方式在生产中存在的一个些问题，主要是rdb引起的memory swap或者disk io性能问题，

1、RDB快照产生

1）redis开启save参数，redis根据数据update频率决定是否执行rdb操作（bgsave）。

2）手动执行save/bgsave命令，包括执行shutdown命令。

3）redis slave请求full sync。包括第一次建立主从关系请求full sync，或者psync失败的时候请求full sync。在2.8版本以前，不支持psync，每次网络抖动或者失去连接都会造成full sync，比较头疼事情。

不管是住save参数触发的rd.持久化或者slave请求full sync引起的rdb持久化，都会导致redis的一些性能问题，特别是单物理机部署多redis实例（端口）时，很容易引发redis性能问题。

2、生产环境下save参数设置

单台物理机部署了多个redis实例（8-16个），机器内存大小64G或者128GB，磁盘存储为两块sas盘做raid1。

我的生产环境下，主从redis实例都关闭了save参数（config set save “”），即redis不会主动执行rdb操作（bgsave）。

主要原因：

1）redis开启save参数，bgsave行为无法主动控制。在业务高峰期同一物理机上多个redis同时进行bgsave，潜在的隐患是：1）机器内存不足，导致出现memory swap，redis性能下降；2）多个rdb操作，导致磁盘出现io瓶颈，系统load持续上升。

2）从库也不开启save参数的原因：内存不足和磁盘io压力过大，导致redis复制超时（默认60s），或者psync不成，多个redis slave同时请求master执行full sync，触发主库开始执行bgsave。

单机多redis实例部署模式下，内存和磁盘io很容易造成redis性能下降。

如果开启bgsave参数，建议磁盘的性能足够好，比如使用ssd盘，或者多块sas盘做raid10。另外机器的物理内存足够大, 且保留充足内存给bgsave完成COW操作（copy-on-write）。

参考文档：

1） Redis latency problems troubleshooting