aof

AOF三种写入策略

1. always

客户端的每一个写操作都保存到aof文件当，这种策略很安全，但是每个写请注都有IO操作，所以也很慢。

2. everysec

appendfsync的默认写入策略，每秒写入一次aof文件，因此，最多可能会丢失1s的数据。

3. 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漏洞限流后续后面慢慢有时间进行学习和更新