AOF三种写入策略
- always
客户端的每一个写操作都保存到aof文件当,这种策略很安全,但是每个写请注都有IO操作,所以也很慢。
- everysec
appendfsync的默认写入策略,每秒写入一次aof文件,因此,最多可能会丢失1s的数据。
- no
Redis服务器不负责写入aof,而是交由操作系统来处理什么时候写入aof文件。更快,但也是最不安全的选择,不推荐使用。
AOF重写
AOF将客户端的每一个写操作都追加到aof文件末尾,指将多个指令相同的key进行重写,生成一个最少命令集
两种重写方式
通过在redis.conf配置文件中的选项no-appendfsync-on-rewrite可以设置是否开启重写,这种方式会在每次fsync时都重写,影响服务器性,因此默认值为no,不推荐使用。
默认不重写aof文件
no-appendfsync-on-rewrite no
客户端向服务器发送bgrewriteaof命令,也可以让服务器进行AOF重写
让服务器异步重写追加aof文件命令
bgrewriteaof
AOF重写方式也是异步操作,即如果要写入aof文件,则Redis主进程会forks一个子进程来处理,如下所示:
重写aof文件的好处
压缩aof文件,减少磁盘占用量。
将aof的命令压缩为最小命令集,加快了数据恢复的速度。
AOF文件损坏
在写入aof日志文件时,如果Redis服务器宕机,则aof日志文件文件会出格式错误,在重启Redis服务器时,Redis服务器会拒绝载入这个aof文件,可以通过以下步骤修复aof并恢复数据。
1、备份现在aof文件,以防万一。
2、使用redis-check-aof命令修复aof文件,该命令格式如下:
修复aof日志文件
$ redis-check-aof -fix file.aof
3、重启Redis服务器,加载已经修复的aof文件,恢复数据。
Redis订阅发布,队列不做详细补充,百度上案例太多了0.0.
总结:
如果你只是单纯把Redis作为缓存服务器,那么可以完全不用考虑持久化,在大多数企业级bat中redis只扮演着cache service角色 。AOF更加安全,阔以及时更新文件到文件中,恢复相对比较慢
关于Redis hash一致性算法 布隆过滤器 hyperLoglog,redis令牌,redis漏洞限流后续后面慢慢有时间进行学习和更新