Eternally Eternally

Redis持久化

in 技术向 read (100698) 文章转载请注明来源!

RDB
采用RDB持久化方式,redis会定期把数据快照保存到一个rdb文件中,并在启动时加载rdb文件,恢复之前保存的数据,可以在配置文件中设置保存数据的时间:
save {second} {change}
例子: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这些指标都需要关注。

jrotty WeChat Pay

微信打赏

jrotty Alipay

支付宝打赏

文章二维码

扫描二维码,在手机上阅读!

本文基于《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权
文章链接:https://www.97hjh.cn/%E6%8A%80%E6%9C%AF%E5%90%91/20180621/Redis%E6%8C%81%E4%B9%85%E5%8C%96.html (转载时请注明本文出处及文章链接)

Redis
发表新评论
博客已坚挺运行
© 2019 本博客模板由 Eternally 基于YoDu二次开发 By 粤ICP备17076045号
前篇 后篇
雷姆
拉姆