有效避免数据丢失!Redis持久化方案选择详解

发表于:2019-5-15 09:43  作者:老王谈运维   来源:今日头条

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 数据库 Redis

  为什么需要持久化呢?
  通常情况下redis的数据全部存储在内存中,数据库一旦故障发生重启数据会全部丢失,即使是在redis cluster或者redis sentinel模式下主从同步数据的恢复仍然需要一段时间。
  持久化功能在于能够有效地避免因进程退出造成的数据丢失问题,在下次重启时利用之前持久化的文件即可实现数据恢复。
  开启Redis持久化之后,数据将存放到磁盘中,数据库执行增量同步的时间要远小于全量同步。在生产环境下故障的数据恢复有着非常重要的作用!
  Redis数据持久化有两种方案
  Redis持久化有两种方案:
  RDB是一种快照式的数据存储,它会周期性的保存当前时间点Redis所有的数据到磁盘中。
  AOF是一种追加式的存储方式,会实时的记录Redis的写操作到磁盘中。
  这两种方案又存在什么样的区别呢?下面让小编一一道来吧~
  1. RDB持久化
  当Redis的写入触发RDB持久化条件后(也可以手动执行dgsave命令来触发),Redis主进程fork一个子进程来创建临时RDB存储文件,创建文件完成后对这个临时文件rename替换原先的RDB文件。RDB文件是一个单文件很适合数据的容灾备份与恢复,通过RDB文件恢复数据库耗时较短,通常1G的快照文件载入内存只需20s左右。
  
  缺点:
  RDB持久化只会周期性的保存Redis数据,当还未触发下一次存储的情况下Redis宕机,则内存中的数据会全部丢失。
  另外当数据量较大的情况下,fork子进程这个操作很消耗cpu,如下图的监控图,每1800s触发的RDB持久化,Redis消耗的cpu都会飙升。在fork子进程过程中可能会发生长达秒级别的阻塞情况。
  
  参数:
  
  save选项如果配置为空save "",则关闭RDB持久化,这个开启RDB持久化触发条件可以配置多条,例如900秒内有1次写入触发快照/300秒内有10次写入触发快照,这个可以根据自身Redis写入情况自由配置来平衡性能与数据安全。
  stop-writes-on-bgsave-error建议开启,当redis bgsave发生错误的时候拒绝客户端的请求,bgsave失败一般是磁盘或者内存空间不够,需要监控来提高数据安全性。
  2. AOF持久化
  AOF是通过保存Redis写操作的命令来实现持久化,使用AOF来持久化,Redis数据的安全性将大幅提高,异常宕机情况下最多丢失1s的数据。AOF文件记录了redis的写操作,格式清晰,易于理解和修改,利于数据的重建。
  
  缺点:
  随着redis写入的增加,AOF存储文件会越来越大,会影响到数据库数据的恢复时间和磁盘空间等,所以我们需要配置AOF重写来缩小AOF文件的体积,这里可使用默认的两个触发条件配置或者我们可以手动调用BGREWRITEAOF命令来触发。
  参数:
  
  appendonly设置是否开启AOF持久化。
  appendfsync有三种持久化模式:always/everysec/no,兼顾数据存储的速度和安全性配置为everysec,每秒钟同步一次数据到磁盘中。
  3. RDB、AOF持久化优劣势对比
  两种方式各有千秋, 下面对比一下两种redis数据持久化方式:
  
  4. 选择
  Redis恢复数据时会先检查AOF文件是否存在,如果不存在就尝试加载RDB文件。
  在实际生产环境中,根据数据量、应用对数据的安全要求、预算限制等不同情况,会有各种各样的持久化策略。如完全不使用任何持久化、使用RDB或AOF的一种,或同时开启RDB和AOF持久化等。
  PS:持久化的选择必须与Redis的主从策略一起考虑,因为主从复制与持久化同样具有数据备份的功能,而且主机master和从机slave可以独立的选择持久化方案。

     上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

【调查报告】你以为的测试行业现状,其实是这样的!

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2019, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道