侧边栏壁纸
博主头像
小俊丶生活日志

天生我材必有用,千金散尽还复来~

  • 累计撰写 120 篇文章
  • 累计创建 144 个标签
  • 累计收到 24 条评论

目 录CONTENT

文章目录

Redis持久化

小俊
2020-06-20 / 0 评论 / 0 点赞 / 1135 阅读 / 0 字
温馨提示:
本文最后更新于2023-06-29,若内容或图片失效,请留言反馈。 部分素材来自网络,若不小心影响到您的利益,请联系我们删除。
  • RDB
    采用RDB持久化方式,redis会定期把数据快照保存到一个rdb文件中,并在启动时加载rdb文件,恢复之前保存的数据,可以在配置文件中设置保存数据的时间:
    save

    例子:save 60 100
    意思是redis会每60s检查一次数据变更的情况,如果发生了100次的数据变化,则进行一次rdb快照保存,可以配置多条保存规则,redis是默认开启rdb快照的,默认的配置如下:
    save 900 1
    save 300 10
    save 60 10000
    也可以通过BG save来手动保存快照

  • RDB的优点:
    1,对性能影响最小。
    2,每次快照都会生成一个完整的数据快照文件,所以可以辅助其他手段保存多个时间点的快照(例如通过用脚本每天把快照备份到其他地方去),可作为灾难恢复手段。
    3,使用RDB文件进行数据恢复比使用AOF要快很多。

  • RDB的缺点:
    1,快照是定期生成的,所以Redis crash(紧急)时或多或少都会丢一些数据
    2,如果数据集非常大而且服务器配置并不是很高,redis会在fork子进程的时候可能会消耗相对较长的时间,影响这期间客户端的请求。

  • AOF
    采用AOF持久化方式时,redis会把每一个请求都记录在一个日志文件里面,在redis重启时,会把AOF文件所记录的的所有写操作重新执行一边,确保数据最新。
    AOF默认是关闭的,如需开启,请在配置文件中修改:
    appendonly yes

  • AOF提供了三种fsync配置:always|everysec|no三种,可以通过appendfsync指定:
    1,appendfsync no:不进行fsync,将flush文件的时间交给os决定,速度最快
    2,appendfsync always:每写入一条日志就进行一次fsync操作,数据安全性最高,但是速度最慢。
    3,appendfsync everysec:折中的做法,交由后台线程每秒fsync一次
    随着AOF不断地记录写操作日志,必定会出现一些无用的日志,例如某个时间点执行了set key1 "123",然后又在某个时间点执行了set key1 "456",那么第一条命令是没有用的,大量的无用日志会让AOF文件过大,变得臃肿,也会让恢复数据的时间更长。所以redis提供了AOF rewrite功能,可以重写AOF文件,只保留能够把数据恢复到最新状态的最小写操作集。

  • AOFrewrite可以通过BGREWRITEAOF命令执行,也可以配置redis定期自动执行:
    auto-aof-rewrite-percentage 200
    auto-aof-rewrite-min-size 128MB
    这两条配置的意思是,redis在每次AOF重写时,会记录完成重写后的AOF日志大小,当AOF日志大小在该基础上增长了200%的时候,会自动进行AOF,同时,如果增长的大小没有达到128MB,就不会进行重写。

  • AOF的优点:
    1,最安全,在启用了appendfsync always时,任何已经写入的数据都不会丢失,使用在启用appendfsync everysec也最多只会丢失1秒的数据
    2,AOF文件在发送断电,宕机等问题时也不会损坏,即使出现了某条日志写入了一般的情况,也可以使用redis-check-aof工具修复
    3,AOF文件易读,可修改,在进行了某些错误的数据清楚操作后,只要AOF文件没有重写,就可以把AOF备份出来,把错误的命令删除,然后恢复数据

  • AOF的缺点:
    1,AOD文件通常比RDB文件更大
    2,性能消耗比RDB高
    3,数据恢复数据比RDB慢

  • Redis数据持久化引发的延迟有哪些:
    1,网络通信的延迟
    2,慢查询命令引起的响应延迟
    3,fork引起的响应延迟
    4,页交换引起的响应延迟
    5,AOF和磁盘IO引起的响应延迟
    6,过期数据引起的响应延迟

  • 数据持久化引发的延迟:
    redis的数据持久化工作本身就会带来延迟,需要根据数据的安全级别和性能要求制定合理的持久化计划:
    1,AOF+fsync always的设置虽然能够绝对确保数据安全,但是每个操作都会出发一次fsync,会对redis的性能有比较明显的影响
    2,AOF+fsync every second是比较好的方案,每秒fsync一次
    3,AOF+fsync never会提供AOF持久化方案下的最优性能
    4,使用RDB持久化通常会提供比使用AOF更高的性能,需要注意的是RDB的参数配置
    5,每一次RDB快照和AOF重写都需要Redis主进程进行fork操作,fork操作本身可能会产生较高的耗时,与服务器CPU和Redis所占用的内存大小有关。根据具体的情况合理配置RDB快照和AOF重写时机,避免太过频繁的fork带来的延迟。

  • 可以用一些常用的命令来检查
    1,这个所谓的慢是可以通过参数slowlog-log-slower-than设定的,默认10000us,也就是10
    ms
    redis>slowlog get num
    2,查看当前实例中那些key比较占用空间(redis-cli的参数)
    redis-cli -bigkeys
    3,查看redis相关的监控信息
    redis>info 相关命令(memory cpu replication stats clients)
    注意:客户端连接数默认限制为10000,total_commands_processed,instantaneous_ops_per_sec,net_io_in_per_sec,net_io_out_per_sec,total_commands,connected_clients,used_memory_human,used_memory_peak_human这些指标都需要关注。

0

评论区