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

此条目发表在redis分类目录。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>